Legal

Privacy Policy

Last updated: 2026-10-06

Zero data plane architecture

Core Spend SDK policy evaluation runs in your application runtime. For supported provider bindings, prompt and completion content travels between your application and the selected model provider; AgentGuard is not an inference proxy. Customer-supplied provider credentials and locally configured signing private keys are not sent to AgentGuard by those bindings.

This boundary does not apply to data you intentionally submit to AgentGuard's hosted website, dashboard, account, support, billing, consent, workflow, or verification features.

What we DO receive or process through hosted features:

• Authentication and account data, including your email and session information through Privy.
• License activation and validation data. A license key submitted for validation reaches the hosted endpoint; signed license decisions use its hash rather than the bearer key.
• AgentGuard Score answers submitted through the plugin's agentguard-score skill or the AgentGuard Score page. They are forwarded to our hosted scoring service to compute the score and, only when you ask for one, the shareable report; nothing else from the plugin is transmitted, and the page sends no email.
• Payment risk check answers submitted on the AgentGuard Score page, to /api/payment-risk or through the hosted MCP tool payment_risk_check: the multiple-choice business profile answers (industry, monthly card payments, chargebacks, fraud claims and the optional questions). We check them against the published options and forward only those answers to our hosted scoring service to compute the estimate. We do not store them and we collect no name or email with them. The scoring service may send our team a notice with the resulting score, tier and industry; that notice carries no identifier for you.
• Configuration files or template text you send to the hosted MCP tools check_setup and score_template at /api/mcp. Our server runs the same published rules the harness check and template score pages run in your browser, in memory, and does not store or log the text. A public GitHub repo you name to check_setup is read through the GitHub API and not stored. The template score and a public repo check record the anonymous count described under Analytics; a pasted setup check records nothing.
• Subscription billing data through Stripe. We do not store full card numbers.
• Managed provider credentials are provisioned and encrypted by AgentGuard before an authenticated runtime fetches them. This is distinct from a customer-supplied provider key.
• Receipt, consent, workflow, policy, builder, and dashboard metadata submitted to hosted APIs. Content-minimization checks reject named prompt, completion, credential, and related data-plane fields from signed receipts, but integrators remain responsible for excluding other sensitive data.
• Strategic inquiry fields: name, company, role, email, intent, free-text context, IP address, user agent, and referrer. The route sends these through Postmark and can store them in Supabase when configured.
• Help-chat messages and an optional reply email. Messages are sent to OpenRouter for a response; escalated transcripts can also be sent to configured Hermes, Telegram, and Postmark destinations. The chat hands off to our team when you ask for a person or a demo, raise an acquisition or IP question, name a team of more than 50, say twice that it is not helping, reach 12 messages, or ask something the model cannot answer, and a handoff emails the last 12 messages, with any email you gave, to our team and posts them to our team's Telegram.
• Site and product analytics may include pseudonymous or account-linked identifiers, attribution, plan, event, and request metadata.

What we do NOT receive from governed Spend SDK calls:

• Your AI agent's prompts when sent through a supported Spend SDK provider binding.
• Your AI agent's completions returned through that binding.
• A customer-supplied model-provider credential used by that binding.
• A locally configured Ed25519 signing private key.

Setup email and optional product updates

When you request setup steps, we store your email address, request date, delivery status and product-update preference in our hosted storage, and send the setup email through Postmark. The updates checkbox is optional and unchecked by default. Leaving it unchecked means you receive only the setup email.

If you opt in, we also send a setup check on day 3, titled "Did it install? Reply if anything broke", and a Team overview on day 14, titled "What Team adds". The automated sequence ends there. We may send occasional product updates manually to opted-in addresses. Each setup and follow-up email includes an unsubscribe link. Unsubscribing stops the remaining follow-ups and product updates, and we retain your preference to honor that choice.

We also use setup email domains to understand company interest. A daily internal digest sent to JP through Telegram groups successfully delivered setup requests by company domain, with the number of distinct addresses and the first-seen date. It excludes common personal email providers. Only domains, counts and dates are sent in this digest, without full email addresses or names. This aggregate use applies to setup requests whether or not you opt in to product updates.

Cookies and analytics

The dashboard uses cookies, local storage, or session tokens to keep you logged in and route you to the right workspace.

Analytics on this site is two things. Vercel Web Analytics is a cookieless visit counter: it runs on every page, sets no cookie and no identifier, stores nothing on your device, and reports the page, the referring site and coarse device and country data to Vercel. It counts clicks on a few named buttons and links the same way, for example Copy install link or Check pasted files: the button's name and nothing else, never anything you type or paste. PostHog does not run until you accept it in the cookie bar, or later through the Cookie settings link, and pages without the cookie bar never load it. Once you accept, PostHog records pageviews, scroll depth, the campaign tags a link carries you in on (for example utm_source and utm_campaign), and a session recording. The session recording masks every input field and the text of anything marked private, includes cross-origin iframe content on pages that have any, and samples about 1 in 10 sessions rather than every visit. If you accept, X's ads pixel also loads and reports the page view to X, so we can see which of our ads on X brought visitors; when you arrive from an X ad it sets a cookie named _twclid for up to 30 days, and X may set cookies on its own domain under its own policy. If you reject or never answer, PostHog and the X pixel never run in your browser; only the cookieless counter does. Separately, when you check a public repo with the harness check or open a shared harness result, run the template score or run the payment risk check (on the website or through the hosted MCP tools), or send an AgentGuard Score from the plugin or the AgentGuard Score page, our server records one count in PostHog: which tool ran (and, for an AgentGuard Score, whether the plugin or the page sent it), its result band or grade, and the day. That count carries no identifier for you and nothing you checked, and it is recorded whether or not you accepted analytics.

Partner and campaign links: if you arrive through one, its code rides along in the page address to checkout and to other pages on this site, so the partner is credited, whether or not you accept analytics. Nothing is stored for that by default. If you accept analytics, we also remember the campaign or partner link you arrived from for 30 days, in the storage listed below; rejecting removes it.

What this stores: once you accept, PostHog's own cookies and local storage keys, all named with a ph_ prefix, and, for 30 days, the campaign or partner link in keys named agentguard_first_utm and agentguard_builder_code, plus X's _twclid cookie when you came from an X ad. Rejecting removes all of these. Either way, your choice itself is kept in local storage under the key agentguard-consent, never in a cookie. Vercel Web Analytics stores nothing on your device, so there is nothing for this choice to remove; it counts as described above either way.

Change your choice any time with the Cookie settings link in the footer.

Third-party processors

Hosted features use processors visible in the local implementation, including Privy for authentication, Stripe for billing, Postmark for email, Vercel and Vercel KV or compatible storage for hosting and account state, PostHog and Vercel Web Analytics for analytics, OpenRouter for help-chat responses and managed inference, and optional Supabase, Hermes, or Telegram destinations. The core Spend SDK provider bindings do not route governed prompt or completion content through AgentGuard, but a selected model provider still receives the inference request.

Optional anonymous install count

Burn's anonymous count is off unless you say yes after a successful report or explicitly turn shared Burn and Spend telemetry on. The question is shown at most once on an interactive terminal. Enter, any answer other than y or yes, or no answer for 15 seconds leaves it off. Burn does not prompt or ping in CI, hooks, library use or a noninteractive terminal.

A yes allows one attempt per install to send burn_first_report to https://agentguard.run/api/beacon. Its exact fields are event, sdk_name (@agentguard-run/burn), sdk_version (Burn version), runtime (Node version), os_family, anonymous_install_id (a random ID shared with Spend), ci_env_detected (false) and tty (true). It sends no prompts, files, paths, project names, session IDs, model names or usage counts.

The choice and random ID stay in the local install.json shared with Spend. Run agentguard-burn telemetry status to inspect the choice, agentguard-burn telemetry on to enable it or agentguard-burn telemetry off to disable it. AGENTGUARD_TELEMETRY=1 explicitly enables shared telemetry. AGENTGUARD_NO_BEACON=1 always turns it off, including when the on switch is set.

Accepted Burn and Spend beacon events are counted as server custom events in our existing Vercel Web Analytics project. The durable count stores the event name, SDK name and SDK version, along with the server event time and a fixed endpoint address. Our Pro plan provides a 12-month reporting window, subject to Vercel's retention terms. The existing short-lived server log receives all eight sanitized fields and receipt time. Request IPs are used for temporary rate limits; we do not forward request IPs, cookies, user agents, install IDs or referrer URLs to these custom events. Opening Burn's Next link makes an ordinary website visit to /burn/next with no query string or install ID. That visit uses the cookieless page counter described above and needs no CLI ping.

Data retention

Hosted account, license, billing, inquiry, support, analytics, workflow, and dashboard data is retained according to the feature and configured processor. The local source does not establish every processor's backup or deletion interval. A signed receipt that you retain remains verifiable with its public key after hosted data is removed; cryptographic signing does not itself publish or retain the receipt.

User rights

If you are covered by GDPR, CCPA, or similar privacy laws, you may request access, correction, export, or deletion of personal information we hold about your account. Email legal@agentguard.run.

International transfers

Hosted account, license, billing, inquiry, support, analytics, and workflow data may be processed in the United States or in regions used by the configured infrastructure providers. The governed SDK inference path remains application to selected provider and does not pass through AgentGuard infrastructure.

Children's privacy

AgentGuard is built for businesses and developers. It is not directed to children under 13.

Contact

Privacy questions can be sent to legal@agentguard.run.