Security

agntdata is built for teams that connect APIs, credentials, databases, webhooks, and agent workflows. We treat security as a core product requirement and design controls around protecting accounts, workspaces, API keys, connected services, Customer Data, and the agent runtime.

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 agntdata and each customer. agntdata is responsible for securing the platform we operate. Customers are responsible for how they configure workspaces, users, keys, connected accounts, prompts, databases, webhooks, and agent instructions.

• »Use least-privilege access for teammates, API keys, OAuth scopes, database permissions, and connected accounts.
• »Rotate keys and tokens promptly when team members leave, workflows change, or compromise is suspected.
• »Review prompts, tool permissions, webhook payloads, and agent instructions before deploying agents to production.
• »Do not send highly sensitive or regulated data unless your agreement and configuration explicitly support that use case.

Dashboard access is authenticated through our identity provider and scoped to workspaces and organizations. API access uses agntdata-issued keys, including workspace-scoped keys and agent runtime keys where applicable.

• »Workspace membership controls user access to dashboard resources.
• »API keys are scoped by workspace or agent context and can be revoked or rotated.
• »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.

agntdata may store API keys, OAuth tokens, webhook secrets, database credentials, and other credentials you provide or authorize so the services 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.

Deployed agents can call tools, APIs, databases, and connected services according to their configuration. Because agents may act autonomously, customers should treat agent configuration as production code and review permissions before deployment.

• »Use scoped agent keys and avoid sharing workspace-wide keys with external systems unless necessary.
• »Limit connected account permissions to the actions the agent actually needs.
• »Inspect and test workflows before enabling high-volume, destructive, or externally visible actions.
• »Monitor usage, credits, webhooks, 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 API prefixes 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 an agntdata account, workspace, API key, connected account, webhook endpoint, deployed agent, 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 agntdata 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.
• »Store API keys in a secrets manager or server-side environment variables, not in source control or browser code.
• »Create separate keys for development, staging, production, and each deployed agent where practical.
• »Set conservative scopes on third-party connected accounts and service accounts.
• »Review webhook endpoints, database tables, agent prompts, and tool permissions 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.