Privacy Policy

agentplanners is operated by Running for the front Limited (registered office: Room 701, Unit 108, 7/F, Tower B New Mandarin Plaza, 14 Science Museum Road Tsim Sha Tsui, Kowloon, Hong Kong) at agentplanners.com. We provide a multi-agent automation platform for advertising and marketing operations. This privacy policy describes how we collect, use, store, and disclose personal information when you use our website and product.

Questions? Reach us at hi@agentplanners.com.

• Account information: email, name, organization name, and any profile fields you choose to provide (via Clerk authentication).
• Connected ad-platform data: when you connect Google Ads or other integrations, we read account metadata (customer ids, campaign names, performance metrics) and any data your goals require us to query.
• Goals, plans, and tool outputs: the prompts you submit, the plans our orchestrator generates, the results of any tool calls (GAQL, BigQuery, sandbox), and the message history of each task.
• Audit logs: actor, timestamp, resource, and outcome of every mutation executed via the platform.
• Operational telemetry: standard server logs, error reports, and aggregate usage counts. We do not sell or use this data for advertising.

agentplanners's use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

We request the following Google OAuth scopes. We only request a scope when you connect the corresponding integration; you may revoke access at any time at myaccount.google.com/permissions.

Limited use: data accessed through these scopes is used solely to provide and improve user-facing features of agentplanners (e.g. running the analyses, mutations, and reports you request). We do NOT use this data for advertising, do NOT transfer it to third parties except as necessary to provide the service (e.g. our hosting provider Vercel, database provider MongoDB Atlas, LLM providers used to plan your tasks), do NOT use it to train or improve generalized AI models, and do NOT allow humans to read the data except (a) with your explicit consent, (b) for security purposes, (c) to comply with applicable law, or (d) in aggregated / anonymized form for internal operations.

Other platforms you can connect ask for their own permissions, and the same limited-use commitments above apply to the data they return:

• Reddit Ads — adsread, adsedit: read your ad accounts, campaigns and performance reports, and apply changes that you approve (status, budgets, bids, targeting, audiences, paused creates). Archiving or deleting a campaign, ad group, ad or audience needs a person's approval every time. No access to messages or to your Reddit profile beyond your Ads membership; posts are read from, and created only as ad creative on, the profiles your ad account advertises as — creating one needs a person's approval every time. An optional adsconversions scope, requested only where a deployment enables it, sends server-side conversion events. Identifiers in conversion events and customer lists (emails, phone numbers, device ids) are canonicalized and SHA-256 hashed on our servers before they are sent to Reddit; plaintext never leaves.
• X Ads — ads.read, ads.write, offline.access: read your X Ads accounts, funding instruments, campaigns, line items, promoted posts, targeting and performance, and apply changes that you approve (status, budgets, bids, paused creates). Deleting a campaign or a line item needs a person's approval every time. No access to your posts, messages, likes or followers; the optional users.read / tweet.read scopes, requested only where a deployment enables them, let us name the connecting user.
• GitHub — read:user, read:org, public_repo (and repo only where a deployment opts in, for private repositories): read repositories, branches, the file tree, issues, pull requests, commits, releases, file contents, traffic and workflow runs, and — with your approval — create issues, comments, issue updates, draft releases, new branches, file changes on a branch (never the default branch) and draft pull requests. Nothing is deleted and nothing is merged; text written by other people in issues and files is handled as data, never as instructions.
• Pinterest — ads:read, ads:write, billing:read, biz_access:read, boards:read, boards:write, pins:read, pins:write, catalogs:read, user_accounts:read: read ad accounts, reports, boards, Pins, catalogs and invoices, and apply ad changes you approve. The write permissions on boards and Pins exist because every Pinterest ad is built on a Pin: new Pins are ad-only (never shown on your profile) unless a person approves a public one. Identifiers in conversion events and customer lists are SHA-256 hashed on our servers before they are sent. We never change billing and never invite or remove business members.
• Klaviyo — exactly the permissions the Agent Planners Klaviyo app declares. Read: accounts:read, campaigns:read, catalogs:read, coupon-codes:read, coupons:read, flows:read, forms:read, images:read, lists:read, metrics:read, segments:read, tags:read, templates:read, tracking-settings:read: reporting on campaigns, flows, sign-up forms, lists, segments and metrics, and reading an object before it is changed. Write: campaigns:write, catalogs:write, coupon-codes:write, coupons:write, flows:write, images:write, lists:write, segments:write, tags:write, templates:write, tracking-settings:write: draft campaigns, templates, lists, tags, segments, images, catalog items (created unpublished), coupons and coupon codes, a flow's status and your UTM tracking settings. We never request access to individual subscriber profiles or events, never add or remove anyone from a list, and never send or schedule a campaign — there is no send path; you send from Klaviyo. Changes go through the approval step (which can be set to auto-approve routine edits); deleting anything, or anything that starts messaging real people (turning a flow live, or changing who a live flow reaches), always waits for a person — it is never auto-approved — and so does publishing a catalog item.
• HubSpot — crm.objects.contacts.read, crm.objects.deals.read, crm.objects.owners.read, crm.lists.read, plus, where your HubSpot plan includes them, crm.objects.companies.read, marketing.campaigns.read, marketing.campaigns.revenue.read and business-intelligence: read-only reporting on deals, contacts, lists, owners, pipelines, marketing campaigns and traffic sources. The connection can see every contact in the portal, but contact personal data — emails, phone numbers, names — is not read into agent results: the agent works in counts and totals, and returns those fields only when a person's own request asks for them on specific people (at most 20 rows, never on a schedule, an automated run or an API key, and never cached). With the default permissions we cannot create, change or delete anything in HubSpot or send email. Write permissions (companies, deals, contacts, lists, marketing campaigns, files, custom events and landing pages) are optional scopes requested only where a deployment enables them; every change then goes through the approval step; contact and list-membership changes, tasks, stage or owner changes, every delete and publishing a page wait for a person; a custom event is recorded in test mode unless a person approves a live one; and no email is ever sent. Removing the portal here does not uninstall the app from HubSpot — you can do that under Settings → Integrations → Connected apps. Per-person HubSpot connections. HubSpot now requires every read and write made on a person's behalf to run with that person's own HubSpot permissions. Each person connects with our user-level HubSpot app (crm.objects.contacts.read, crm.objects.deals.read, and optionally crm.objects.companies.read and the companies, deals and contacts write scopes); we store that person's own tokens, bound to them, and every HubSpot call the agent makes for them — a task they started, a schedule, alert rule or dashboard they created, an API key they created, a change they approved — uses only their connection, so it sees and changes only what they can see and change in HubSpot. Another person's connection is never used; when the person has not connected, the call is refused. Their connection ends when they disconnect it, remove the app in HubSpot, or leave the workspace.
• Stripe — Stripe Connect. The scope is read_only where Stripe has enabled read-only connections for our platform, and otherwise read_write, the scope Stripe grants a Connect platform. We read charges, payment intents, refunds, disputes, payouts, balance transactions, customers, subscriptions, invoices, products, prices, checkout sessions, coupons, promotion codes and payment links. On a read_write connection the agent can also manage the catalogue — customers, products, prices, coupons, promotion codes and payment links — each created inactive, with activation and deletes approved by a person. It never moves money: we never create a charge, refund, payout or transfer, never touch a subscription, invoice or balance, and never change an account setting. Customer names, emails, phone numbers and addresses reach the agent masked; identified customers are returned only when a person, in an interactive task they started, asks for them — never to an API key or an automated run. Removing or disconnecting a Stripe account here also revokes our access in Stripe once no workspace uses it.
• Snapchat Ads — snapchat-marketing-api (Snap's one scope that both reads and writes the Ads API) and snapchat-profile-api (read the Public Profiles a creative is attributed to): read your ad accounts, campaigns, ad squads, ads, creatives, segments, pixels and stats, and apply changes you approve — status, budgets, bids, targeting, schedules, creatives, segments, and new campaigns, ad squads and ads that are always created paused. Deleting anything (Snapchat has no archive state), removing people from a customer list and sending live conversion events need a person's approval every time; conversion events go to Snap's validate endpoint unless a person approves a live send. An optional snapchat-offline-conversions-api scope is requested only where a deployment enables it. Identifiers in customer lists and conversion events are normalized with Snap's rules and SHA-256 hashed on our servers before they are sent; plaintext never leaves.
• LinkedIn Ads — r_ads, r_ads_reporting, rw_ads, r_organization_social, w_organization_social (rw_conversions only once LinkedIn approves the Conversions API): read the ad accounts your member holds a role on, their campaign groups, campaigns, creatives, dark posts, conversion rules, the Insight Tag and analytics, and apply changes you approve — status, archive, budgets, bids, schedules, targeting, UTMs, tracking parameters, conversion rules, media, and new campaign groups, campaigns and creatives that are always created paused or as drafts. Deleting anything, archiving a dark post, publishing a public post or editing one already published, sending conversion events (LinkedIn has no test mode), deleting an audience, blocking a domain on the Insight Tag and changing who has access to an ad account need a person's approval every time. w_member_social (sharing as the member), rw_dmp_segments (Matched Audiences) and r_marketing_leadgen_automation (Lead Sync) are opt-in and requested only where a deployment enables them; lead-form answers are personal data and are never returned to the agent on any lane. Identifiers in audience uploads and conversion events are SHA-256 hashed on our servers before they are sent.
• Shopify (the Shopify app, beside a pasted Admin token that asks Shopify for nothing) — the consent screen lists exactly the scopes this deployment requests; by default read_products, read_orders, read_customers and read_inventory. Write scopes are requested only where a deployment enables them (a pasted token carries the scopes you gave it), and every store change then goes through the approval step; deleting a discount code, an automatic discount, a collection or the app's web pixel, an absolute inventory set, repricing variants, deactivating a code (or ending or postponing it by date), a discount of 50 % off or more and a product status flip wait for a person. The customer list leaves out customer names unless a person's own request, in an interactive task that person started, asks for identified customers — never over MCP, in an automated run, on a schedule or on a dashboard; the generic Admin query tool returns what Shopify sends. No dedicated tool writes orders or checkouts, and building a cart returns a checkout link for a person to complete. The generic mutation tool, though, reaches any mutation the store's grant or token allows, order and payment mutations included; some of those always wait for a person, among them every delete mutation, refundCreate, returnProcess, orderCapture, orderCancel, transactionVoid, draftOrderComplete and orderCreateMandatePayment. Removing the store here deletes our tokens; you can also uninstall the app from the Shopify admin, which revokes it on Shopify's side.
• SHOPLINE (the registered app, beside a pasted private-app token) — the consent screen lists exactly the scopes this deployment requests; by default read_store_information, read_products, write_products, read_orders, write_orders, read_customers, read_inventory and write_inventory. Granting a write scope never makes the agent autonomous: every store change goes through the approval step, and deleting a discount code, an absolute inventory set, repricing variants, deactivating a code (or ending or postponing it by date), a discount of 50 % off or more and a product status flip wait for a person. The customer-list and sales-report tools leave out customer names, emails and phone numbers unless a person's own request, in an interactive task that person started, asks for identified customers (even then SHOPLINE masks email and phone in the customer list) — never over MCP, in an automated run, on a schedule or on a dashboard; the generic Admin read tools return what SHOPLINE sends, customer details included.

You can disconnect any of them at any time from Integrations; tokens are encrypted at rest and deleted from our database when you disconnect. You can also remove the app from the platform's own settings, which revokes it on their side.

• To run the agent workflows you ask for — query metrics, propose changes, execute approved mutations against connected accounts.
• To produce reports, charts, and audit records that you can view, share, or export.
• To send transactional emails (approval requests, failure alerts) via Resend.
• To improve product reliability through error monitoring (logs do not include account-data payloads beyond what's needed to diagnose).
• To enforce our Terms of Use and protect the platform against abuse, fraud, or security threats.

• Authentication: Clerk
• Hosting + Workflow runtime: Vercel
• Database: MongoDB Atlas
• File storage: Vercel Blob
• LLM providers: Vercel AI Gateway (routes to providers such as Anthropic, Google, OpenAI). Prompts include the goal + relevant context from your connected accounts; responses are stored against your task.
• Sandbox: Vercel Sandbox (Python execution for analysis / charts)
• Email: Resend (transactional emails only)
• Search: Perplexity (via AI Gateway) and searchapi.io for web lookups when a task requires them

Finished tasks and their messages are deleted automatically after your workspace's task-history retention period — 90 days by default; an admin can set 7 to 3,650 days or keep them. Account, audit, and integration records are retained for the duration of your account. Disconnecting an integration revokes our access and stops further data collection from that source.

LinkedIn Ads data follows LinkedIn's limits, whatever the workspace setting: tasks that read LinkedIn Ads data are deleted after at most 365 days (a shorter period can be set in Settings), and when a workspace no longer has a LinkedIn account connected, the LinkedIn data it holds — those tasks, the saved memory of its LinkedIn accounts and their alert rules — is deleted within 10 days.

You can delete individual tasks, audit entries, and assets through the product. To delete your account and all associated data, email hi@agentplanners.com and we will action your request within 30 days (LinkedIn data within 10 days).

Depending on your jurisdiction (e.g. GDPR for EU residents, CCPA for California residents), you may have the right to access, correct, port, restrict, or delete your personal information, and to object to certain processing. Submit requests to hi@agentplanners.com and we will respond within the timeline mandated by applicable law.

We use industry-standard practices: TLS in transit, AES at rest where supported, encrypted storage of OAuth refresh tokens, secrets never logged, and strict allow-listing of redirect URIs in our Google Cloud project. No system is impenetrable — please use a unique password and 2FA on your account.

agentplanners is not directed to children under 16, and we do not knowingly collect personal information from children.

By using the service you consent to your information being transferred to and processed in the United States and other countries where our service providers operate.

We may update this policy from time to time. Material changes will be announced via email to the address on file or via an in-app banner. The "Last updated" date at the top reflects the current version.

For privacy questions, complaints, or data-subject requests: hi@agentplanners.com.

Postal address: Running for the front Limited, Room 701, Unit 108, 7/F, Tower B New Mandarin Plaza, 14 Science Museum Road Tsim Sha Tsui, Kowloon, Hong Kong.