Legal · Privacy Policy
pactflow governs agent traffic on behalf of our customers, so most of the data we touch is theirs, not ours. This policy explains both halves. Effective June 8, 2026.
This policy covers pactflow, Inc. ("pactflow", "we") and applies to pactflow.xyz, the pactflow control plane, the CLI and SDKs, and our sales and support channels. Because of what the product does, we wear two hats, and your rights depend on which hat we're wearing for the data in question.
Controller. For data about you as a visitor or account holder, your name, work email, login events, billing details, and how you use our website and console, pactflow decides why and how the data is processed. We are the controller, and this policy is the primary document that governs it.
Processor. For agent traffic and policy content that flows through the platform, our customer is the controller and we are a processor acting on documented instructions under a Data Protection Agreement. The customer decides what their agents process; we enforce their policies against it and keep the records they configure. If your data reached pactflow because a company you interacted with runs its agents through us, that company controls the data and your requests route to them.
The service is built for organizations and is not directed at children. We do not knowingly collect data from anyone under 16, and if we learn we hold such data as a controller, we delete it.
This policy does not cover what our customers do with their own agents; that is governed by their privacy notices. It also does not cover the model providers customers connect through their own keys, or third-party sites we link to, each of which has its own terms.
We keep the controller-side footprint deliberately small. It consists of:
One line we do not cross: prompt and completion bodies never appear in our product analytics. Usage metadata records that an enforcement decision happened, not what the agent said. The content of agent traffic is processor-side data, covered below, and stays out of every analytics pipeline we operate.
When your organization routes agents through pactflow, the platform processes prompts, completions, tool-call arguments and results, and the policy definitions that govern them. This is the data the product exists to govern: every call is evaluated against compiled policy inline, and the decision is written to the signed audit log.
Whether any of this contains personal data is the customer's call, and it varies enormously: a code-review agent's traffic may contain none, while a support agent's traffic contains whatever the customer's own users typed. That is precisely why the customer, not pactflow, decides what their agents are allowed to process, and can enforce that decision in policy, for example by compiling redact() rules that strip PII fields before a prompt ever reaches a model.
Traffic bodies are retained for the window the customer configures, by default 90 days, so that audit replay works: an auditor or incident responder can reconstruct exactly what an agent saw and did at the time a decision was made. Customers can shorten the window, lengthen it to meet their own regulatory obligations, or set it to zero and keep decision metadata only.
As a controller, we process personal data to:
As a processor, we process agent traffic for exactly one purpose: executing our customer's documented instructions, which in practice means enforcing their compiled policies and maintaining their audit records. Anything beyond that requires a change to the DPA, not a change to this page.
Automated decision-making. pactflow's policy engine makes automated decisions about agent calls, allow, hold, or block, but not about people. We make no controller-side decisions producing legal or similarly significant effects on individuals within the meaning of GDPR Article 22. Whether a customer's agents make such decisions is the customer's determination to make and disclose.
Where the GDPR or UK GDPR applies to our controller-side processing, we rely on:
For processor-side data, the legal basis is our customer's to establish. Our DPA obligates us to assist them in meeting it, including with records of processing and data protection impact assessments.
Personal data is never sold here, and advertisers never see it. We share data with a short list of subprocessors, each bound by a written agreement imposing obligations at least as protective as our DPA:
Notably absent from that list: model providers. pactflow does not proxy your agent traffic through model accounts we own. Customers bring their own model keys, so completions flow under the customer's direct agreement with their model provider, governed by that provider's terms with them, not with us. The current subprocessor list is available on request to legal@pactflow.xyz, and DPA customers receive at least 30 days' notice before we add or replace a subprocessor, with a right to object.
We may also disclose data when the law compels it. If a request targets processor-side data, we redirect the requester to our customer unless legally barred from doing so, and we notify the customer unless prohibited.
The managed service runs in the customer's chosen region, and agent traffic is stored in-region. Where controller-side data leaves the EEA, the UK, or Switzerland, we rely on:
Copies of the relevant transfer mechanisms, and our transfer impact assessment summary, are available through legal@pactflow.xyz.
Retention periods by category:
The audit log needs its own paragraph, because immutability and deletion rights pull in opposite directions. The log is append-only and hash-chained; deleting a single entry would break the chain and defeat the point of tamper-evidence. So deletion requests against audited data follow a restrict-then-purge model: the affected entries are immediately restricted, cryptographically shredded of readable personal content while the hash chain stays intact, and the residual entries purge in full when the customer's retention window expires. You lose the personal data; the customer keeps a verifiable record that a decision occurred.
Like everything else in pactflow, retention is compiled policy, not a settings toggle someone can quietly flip. A change to a retention window is a policy change, which means it is diffed, routed for approval, and recorded in the audit log itself.
# retention is compiled like any other policy policy "audit-retention": traffic: retain(days=90) audit: append_only(signed=true) deletion: restrict_then_purge()
Encryption everywhere, per-tenant isolation, just-in-time production access, signed policy artifacts, and independent SOC 2 Type II and ISO 27001 audits, the full control set, including our fail-closed enforcement design and vulnerability disclosure program, is documented on the Security page. If you believe you've found a vulnerability, contact security@pactflow.xyz.
Breach notification. If a personal data breach affects data we control, we notify affected individuals and, where required, supervisory authorities within the timelines the law sets. If it affects data we process for a customer, we notify that customer without undue delay, and in no case later than 72 hours after we become aware, with enough detail for them to meet their own obligations.
Your jurisdiction may grant you rights over your personal data: to inspect it, fix it, erase it, or take a copy with you, plus the rights to restrict or object to processing and to pull back consent you gave earlier. Send requests to privacy@pactflow.xyz; identity gets verified, answers arrive inside 30 days, and a first request always costs nothing. If we need more time on a complex request, we tell you why and when to expect an answer.
EEA, UK, and Switzerland. You have the full set of GDPR rights listed above, plus recourse to your data protection authority though talking to us first tends to be faster.
California and other US states. You have the rights to know, delete, correct, and port, and the right not to be discriminated against for exercising them. We do not sell personal information or share it for cross-context behavioral advertising as those terms are defined in the CPRA, so there is nothing to opt out of, but we honor opt-out preference signals anyway.
If your request concerns data we process on a customer's behalf, agent traffic in a customer's workspace, we will identify the customer where we lawfully can and route your request to them, since they, as controller, are the party able to act on it. Our DPA obligates us to assist them in responding.
The console uses strictly necessary session cookies (pf_session, pf_csrf) for authentication and request-forgery protection; they expire when your session does and carry no tracking function. Our website analytics are first-party and cookieless: aggregate page counts, no cross-site identifiers, no fingerprinting, nothing to consent-wall.
We honor the Global Privacy Control signal, and we set no advertising or third-party tracking cookies anywhere on the site. There is no cookie banner because there is nothing a banner would be asking permission for.
Every revision of this policy moves the effective date above and lands as an entry in our public changelog. For material changes, we email workspace administrators at least 30 days before the new terms take effect, and, where a change affects processor-side commitments, we follow the amendment process in the DPA. Continued use after the effective date constitutes acceptance.
Privacy questions and requests: privacy@pactflow.xyz. Contractual and DPA matters: legal@pactflow.xyz. Postal: pactflow, Inc., a Delaware corporation, attention Privacy. EU and UK representatives are named in our DPA for customers who require them.