Growth Method's Security Details

Growth Method connects AI agents to the systems where marketing teams already work: CRMs, email tools, customer data warehouses, and collaboration tools. We recognise that running agents against systems holding sensitive customer data raises the bar on security. While we are a small team, we work hard to punch above our weight on security.

This document covers our security practices and policies. If you have a question it doesn’t answer, email security@growthmethod.com.

General practices

• Access to servers, source code, and third-party tools is secured with two-factor authentication.
• We use strong, randomly generated passwords that are never re-used.
• Employees and contractors are given the lowest level of access that allows them to get their work done. This rarely includes access to production systems or customer data.
• Employees and contractors sign an NDA before gaining access to sensitive information.
• We don’t copy production data to external devices, such as personal laptops.

Account authentication

Signing in is hardened well beyond a username and password:

• Passkeys and two-factor authentication are available on every account. A passkey signs you in with your device’s biometrics and can’t be phished. Two-factor authentication adds a one-time code on top of your password.
• Breached passwords are rejected. Passwords must be at least 12 characters and are checked against known public breaches, so one that has leaked elsewhere can’t be used here. The check never sends your password off our server.
• Separate rate limits guard the sign-in, two-factor, and sign-up steps independently against brute-force and credential-stuffing attempts.
• Sign-in doesn’t reveal which emails have accounts. Every attempt does the same work whether or not the account exists, so an attacker can’t use response timing to tell which emails are registered.
• Changing your password signs you out everywhere else, so a stolen session ends the moment you reset.
• The automation account that runs scheduled work can never sign in. It has no usable password and no interactive session.

Access control and organisational security

Access to our own API and to the MCP endpoints we expose is authenticated with scoped, revocable per-user tokens, never a shared secret. Team membership is re-checked on every request, including every agent action and API call, so a token only works while its owner is still on the team. When someone is removed from a team, their tokens lose access and their access to the app and to connected systems ends immediately, not at the end of a session.

Agent and AI tool security

The bulk of Growth Method’s security work concerns how agents interact with connected systems on behalf of customers.

Default deny on every tool

Every agent runs with the minimum tool access it needs for the job, and we default to closed:

• Read-only tools run automatically. A tool that only reads data is safe to run without interrupting you.
• Everything else needs explicit human approval. Any tool that can change, send, or delete something, and any tool that doesn’t declare what it does, is held for an Approve or Reject decision before it runs.

The Model Context Protocol lets a tool advertise that it is read-only, but the standard is clear that this is a hint and clients must treat it as untrusted. We follow that to the letter: a tool runs unattended only when it positively declares itself read-only. Anything unannotated is treated as destructive and gated.

Autonomous runs are double-gated

A scheduled agent can act on its own, but a connected-tool write fires without a human Approve only when two independent conditions are true at once: the run is the automation account, and it carries the scheduler’s autonomous-run marker. A person working in chat is neither, so a human session can never trigger an automatic write. Automated tests confirm that a human session is still held for approval even if that marker is forced on.

Agents decline rather than half-finish

If a plan needs a step no tool can perform, or a write fails, or a result can’t be verified, the agent stops rather than pressing on. It leaves the campaign at the planning stage and records what a person needs to finish. Campaigns also move only forwards through their stages, so a stage is never run twice.

Stage changes are locked to purpose-built workflows

No chat conversation can move a campaign through its lifecycle stages. The tool agents use to edit campaigns has no stage control at all outside the dedicated planning and launch workflows, so the capability is absent rather than gated behind approval, and no prompt can talk an agent into skipping or forcing a stage. Marking a campaign complete is reserved for a person, in the app.

Every tool call is logged

Every tool call an agent makes is logged: what was requested, what was returned, when, which agent made it, and on whose behalf. Logs are available for audit.

Integrations and MCP authentication

OAuth preferred over static keys

Where a system supports it, we connect over OAuth rather than a static API key, so access is scoped, revocable, and never a long-lived shared secret. OAuth has been battle-tested for over fifteen years and carries extensive security guidance. We support the modern Model Context Protocol authorization profile in full: OAuth 2.1 with PKCE, both dynamic client registration and client ID metadata documents for establishing client identity, authorization-server and protected-resource metadata discovery, and resource indicators that bind each token to the specific server it was issued for. Where only an API key is available, a team manager supplies it and we encrypt it at rest.

Remote, first-party servers only

We never run MCP servers on user machines. All MCP servers run in our managed environment, behind authentication and access controls. Where a vendor (Slack, HubSpot, Notion, Salesforce, and others) operates an official first-party remote MCP server, we use it; first-party hosted servers also tend to be better maintained and more capable than their open-source equivalents. Where no first-party server exists, we run a sandboxed instance of an open-source server in our managed environment, never on a user’s machine. Integrations can only be connected through OAuth or a manager-supplied API key, never an anonymous or self-discovered server.

Credential handling

API keys and OAuth tokens for connected systems are never distributed to end users and never stored in plaintext. Credentials are managed centrally, encrypted at rest at the application layer, scoped per integration, and rotated. When a user is removed, access to connected systems is revoked at the source.

Integration records

An integration record is locked the moment it is created. Credentials cannot be read back, modified, or exported through the application. To rotate or revoke an integration, the record is deleted and replaced.

Supply chain protection

The packages we depend on, and the open-source MCP servers we run, can themselves become attack vectors. Recent compromises in nx, litellm, axios, and bitwarden each gave attackers a path to code execution on every machine that pulled in the malicious update. In each case the compromise was detected within hours or days of publication.

Our main defence is time. We never install an npm or Composer package released in the last seven days. A freshly published malicious version is almost always caught and pulled within that window, so code only reaches our servers after a new dependency has survived a seven-day cooldown and passed our checks. On top of that:

• Every change scans all dependencies, including transitive ones, for known vulnerabilities and malware.
• Lock files are committed and installs are frozen to them, so the exact, reviewed versions are what ship.
• Dependency versions are pinned; nothing updates automatically.
• The set of packages allowed to run install-time code is kept deliberately minimal, as a security decision rather than a convenience.

Encryption

All communication between Growth Method clients and our backend is encrypted in transit using TLS 1.2 or higher.

The most sensitive data we hold, the OAuth tokens and credentials for your connected systems, is encrypted at the application layer with AES-256, so it is unreadable even to someone with direct database access. That encryption travels with the data and doesn’t depend on the host.

Application and transport security

In production we enforce, on every response:

• HTTP Strict Transport Security (a one-year max-age, including subdomains), so browsers refuse to talk to us over plain HTTP.
• Secure session cookies, marked Secure, HttpOnly, and SameSite=Lax.
• X-Frame-Options: SAMEORIGIN to prevent click-jacking, X-Content-Type-Options: nosniff to stop MIME sniffing, X-XSS-Protection: 1; mode=block as a defence-in-depth fallback for legacy browsers, and a strict Referrer-Policy.

Data retention and logging

Application and audit logs are retained in hot storage for 30 days, then archived to cold storage for 12 months before permanent deletion. Customer data is retained for the duration of your subscription and deleted within 30 days of cancellation, or sooner on request.

Software development and vulnerability detection

• Code is tested in a staging environment before deployment to production.
• All deployments are tracked and auditable.
• Our codebase, infrastructure, and dependencies are continuously scanned for known vulnerabilities with automated static analysis, linting, and dependency and malware scanning on every change. Vulnerable dependencies are patched and redeployed rapidly.

Hosting

Our backend infrastructure runs on DigitalOcean, provisioned and managed through Laravel Forge. DigitalOcean’s data centre operations have been accredited under:

• ISO 27001
• SOC 1 Type II and SOC 2 Type II
• PCI DSS
• CSA STAR Level 1

FAQs

Is my customer data used to train AI models?

No. Data passing through Growth Method is not used to train any model, by us or by any model provider we route to.

Are you SOC 2 or ISO 27001 certified?

While we’d eventually love to achieve these certifications, we don’t hold them at this time.

How do you authenticate connections to my other tools?

Wherever a system supports it, over OAuth, using the modern Model Context Protocol authorization profile (OAuth 2.1, PKCE, dynamic client registration and client ID metadata documents, metadata discovery, and resource indicators). Where only an API key is available, a team manager supplies it and we encrypt it at rest.

Is my data encrypted?

In transit, yes, everywhere, over TLS 1.2 or higher. The credentials for your connected systems are additionally encrypted at rest at the application layer with AES-256, so they can’t be read even with database access.

Can an agent take a destructive action without my knowledge?

Without your knowledge, no: every tool call an agent makes is logged, and every run is a conversation you can reopen in full, so nothing it does is hidden.

Without your approval is your choice. Agents are Manual by default and hold anything that changes a connected tool (sending email at scale, deleting records, posting to a public channel) for your explicit Approve. You can switch an individual agent to Autonomous, which lets it act on your connected tools without approving each step and, once you accept an explicit on-screen acknowledgement, take a scheduled campaign all the way to launch on its own. We record who accepted that and when. It still can’t run away: it works one fixed stage at a time, never loops, and if any step needs a person or a tool action fails it stops rather than launching something half-finished.

What happens to my connected-system credentials when I cancel?

Credentials are revoked at the source and removed from our system.

Do you run MCP servers on my team’s laptops?

No. All MCP servers run in our managed environment. Nothing is installed on your team’s machines.

How do I report a potential vulnerability or security concern?

Please email us at security@growthmethod.com and we’ll get back to you as soon as possible.

Any further questions?

Email us and we’ll happily update this document.