Security at Frayme

Last updated: 17 September 2026

This page summarises how Frayme protects the Service and the data that passes through it, and how to report a security problem. The contractual version of these measures is Annex B of our Data Processing Agreement, which is what a customer's procurement team should rely on; if this page and the DPA differ, the DPA governs. The narrative part of this page (down to the end of "Certifications") is a description of our practices, not a warranty, and does not form part of the Terms. The Vulnerability Disclosure Policy below is different: it does form part of the Agreement, as clause 2 of the Terms provides, and is ranked in the order of precedence in clause 23.4 of the Terms, so the authorisation and safe harbour it gives are binding on Frayme. Capitalised terms have the meaning given in the Terms of Service.

The short version

Frayme composes interface specifications. A request contains a prompt and, optionally, a DATA block of your own content.

Request content (the prompt, the DATA block, every model output for that request and the interface specification we return) is stored in Frayme's database (Supabase, Frankfurt, EU) for up to 60 days. We keep it for that period so that we can provide the Service including idempotent retries, support you and debug failed generations, investigate abuse, fraud and security incidents, protect the integrity of the Service, and attribute cost. At 60 days the content is irreversibly deleted from the record. What survives is non-identifying technical signal only: the failure category, the component and property names our validator flagged, timings, token counts, cost, which model answered and the validation result, with workspace, user, API-key and trace identifiers removed. The content is deleted, not masked. Usage and billing records, which contain no content, are kept for the life of your account, and the billing totals we need for invoices and tax for approximately six years, as UK law requires.

Where your data is processed. Account data, workspace data and stored request content rest in the European Union (Frankfurt). The application, the API and model inference run on United States providers (Vercel for the application, the API and the AI Gateway, and Modal for Frayme's own model) under the EU Standard Contractual Clauses (2021/914) supplemented for UK transfers by the ICO International Data Transfer Addendum. No region is pinned on Modal: Frayme's own model runs on Modal's global infrastructure, so requests are routed through Modal's servers in Virginia, United States, and containers run wherever Modal has capacity. The fallback model (Anthropic, reached through the Vercel AI Gateway) is also in the United States and is used only when the primary model's output fails validation. Modal's security documentation states that for web endpoints, which is how we call the model, request and response payloads are "Not stored" and are "proxied directly to your container", and container logs are retained for one day on our current plan. Modal's Data Processing Addendum is incorporated by reference into its agreement with us and includes the EU Standard Contractual Clauses and the ICO Addendum; Vercel's Data Processing Agreement does the same. We do not claim Data Privacy Framework certification for Modal or Vercel.

Operational tracing carries no content. Our tracing provider, Langfuse, receives metadata only: timings, token counts, cost, model name, validation outcome and failure category. It receives no prompt, no DATA block and no model output.

Frayme has no relationship with OpenAI and sends no data to OpenAI. The @ai-sdk/openai-compatible package in our code is a protocol adapter for Frayme's own model; it is explained at frayme.ai/sub-processors.

Frayme does not train, fine-tune or improve models on Customer Content. See clause 9.4 of the Terms of Service. Where a generation fails validation, we may create anonymised material from it, from which all personal data and all information identifying you or any individual has been removed so that it can no longer be linked to you or to them, and we may use that anonymised material to improve and train our models. You instruct us to carry out that anonymisation. Raw prompts, raw DATA blocks and raw model outputs are never used for training.

How we protect data

• Encryption: TLS 1.2 or higher for everything in transit; our database provider encrypts stored data at rest (AES-256).
• Tenant isolation: workspace-scoped access enforced by row-level security at the database layer.
• Credential security: API keys are shown once at creation and stored only as one-way hashes; they are verified without plaintext storage. Rotation and revocation are available in the dashboard at any time.
• Access control: production access is limited to Frayme's founders, each using a named account, with multi-factor authentication enforced on every console we administer: database, application hosting, model hosting, payments, source control, and the mailbox that receives vulnerability reports and breach notices.
• Data minimisation and retention: request content is held for up to 60 days and then irreversibly deleted by a scheduled job in our database, leaving only the non-identifying technical signal described above; content deleted at 60 days leaves our database backups as those backups roll over, within a further 7 days. We hold no other copy of your content, and our tracing provider receives none.
• Payment isolation: card data is handled entirely by Stripe (PCI DSS Level 1). Full card numbers never reach Frayme's systems.
• Monitoring and abuse controls: request, authentication and error logs kept by our hosting, database and model-hosting providers, which on our current plans retain them for a short period, typically one to seven days, unless we export them; per-plan rate limiting; and abuse controls including API-key revocation and workspace suspension.
• Resilience: account, workspace and configuration data is held on managed, replicated database infrastructure with automated backups taken by our database provider. We test a restore of a production backup at least once a year.
• Software security: staging and production are separate environments with separate databases and credentials, and changes are tested in staging before release. Dependencies are monitored for known vulnerabilities by automated scanning on every repository and patched promptly.
• Vendor management: we contract with each sub-processor under its data processing terms, which incorporate the EU Standard Contractual Clauses and the ICO International Data Transfer Addendum where the provider processes data outside the UK and EEA, or rely on an adequacy decision, including the EU-US Data Privacy Framework and its UK Extension, where the provider is certified. The Anthropic fallback is reached through Vercel's AI Gateway. We review the list, and each provider's security and transfer position, whenever a provider is added or changed. The full list is at frayme.ai/sub-processors.
• Incident response: we follow a written incident-response runbook covering detection, assessment, containment, recovery and notification. If a personal data breach affects your data we will notify you without undue delay and in any event within 48 hours of becoming aware of it, as set out in clause 11 of the DPA, and we will tell you what happened, what data was affected and what we are doing about it.

What we ask of you

• Keep API keys server-side. Do not embed them in client-side code, mobile apps or public repositories.
• Rotate keys when someone leaves your team, and immediately if you suspect exposure.
• Do not send prohibited data to the API. Unless separately agreed with Frayme in writing, that means: special categories of personal data (including health, biometric or genetic data), personal data relating to criminal convictions or offences, full payment card numbers or financial account credentials, government-issued identification numbers, or personal data of children (for this purpose, anyone under 16). See clause 8.3 of the Terms.
• Validate Outputs before rendering them to your end users.

Certifications

Frayme does not currently hold SOC 2 or ISO 27001 certification. We are happy to answer a reasonable written security questionnaire. Write to support@frayme.ai. Under clause 9.1 of the DPA we respond to one such questionnaire from each customer in any 12-month period, unless Data Protection Laws or a personal data breach require otherwise. Prospective customers may send one on the same basis; this page and Annex B of the DPA are our standard answers, and we will usually point you to them first.

Vulnerability Disclosure Policy

If you believe you have found a security vulnerability in Frayme, we want to hear from you. If you follow this policy, we will not take legal action against you for your research.

How to report

Email support@frayme.ai with the subject line "Security". Include enough detail for us to reproduce the issue: the endpoint or page, the steps, what you observed, and any proof-of-concept. Please send only what we need to reproduce the issue, and do not include anyone else's personal data. We do not currently publish a PGP key; if your report contains sensitive detail, say so in a first email and we will arrange a secure channel.

We will:

• acknowledge your report within 3 working days (Monday to Friday, excluding public holidays in England);
• give you an initial assessment within 10 working days;
• keep you updated while we fix it;
• tell you when it is resolved; and
• credit you publicly if you would like us to.

Frayme does not currently operate a paid bug bounty.

Scope

In scope: frayme.ai, app.frayme.ai and the Frayme API, and the @frayme/* packages published on npm together with their public repositories. You may send requests to those endpoints even though they run on third-party infrastructure.

Out of scope: our documentation site and any third-party embeds on the marketing site, and the systems, control planes and other tenants of our providers (Vercel, Supabase, Modal, Langfuse, Stripe, Anthropic, Google and Resend). Report issues in those to the provider concerned.

Safe harbour

If you make a good-faith effort to comply with this policy, Frayme will treat your testing of the in-scope systems as authorised by Frayme for the purposes of the Computer Misuse Act 1990 and our Terms; will not bring a civil claim against you, and will not make a complaint or referral to law enforcement, in respect of that testing; and, if a third party brings a claim or complaint against you for activity that complied with this policy, will confirm on request that we authorised it.

Please understand the limits of what we can promise. We can authorise access only to the systems we control. We cannot authorise access to our providers' infrastructure, to other customers' accounts or data, or to anything else belonging to a third party, and we cannot give you permission on their behalf. We cannot bind the police, the Crown Prosecution Service or any other prosecutor or regulator: a prosecution under the Computer Misuse Act 1990 does not depend on a complaint from us, and nothing here prevents us from complying with a court order or a lawful request for information.

To stay inside this safe harbour, please:

• only test against your own account and your own data;
• stop as soon as you have confirmed a vulnerability, and do not access, modify, delete or exfiltrate anyone else's data;
• tell us immediately, and delete what you hold, if you do reach another customer's data or personal data by accident, so that we can assess whether it is a personal data breach we must report;
• do not degrade the Service for others: no denial-of-service, no load or stress testing, no automated scanning that generates significant traffic;
• do not use social engineering, phishing or physical attacks against Frayme's people, offices or suppliers;
• do not target our providers' own systems, control planes or other tenants: send requests only to the in-scope Frayme endpoints, and report provider issues to the provider; and
• give us a reasonable opportunity to fix the issue before disclosing it publicly. Our default is 90 days from the date we acknowledge your report; we will usually be much faster, and we may ask you to agree a longer period where a fix depends on a third-party provider or where earlier disclosure would put customers' data at risk. Please do not include any personal data or live customer content in a public write-up.

Testing that stays within these limits is authorised for the purposes of section 6 of the Acceptable Use Policy, and we will not treat it as a breach of clause 7.2(b) of the Terms of Service. Testing that goes outside them is not authorised.

Out of scope reports

Reports of the following are welcome but will usually be closed without action: missing security headers with no demonstrated impact; weak SSL/TLS configuration without a working exploit; rate-limit findings that match our published limits; self-XSS; clickjacking on pages with no sensitive actions; missing or permissive SPF, DKIM or DMARC records without a demonstrated spoofing impact; software version disclosure without a working exploit; issues that require a compromised or rooted device, or physical access; the content of generated interface specifications, for example unexpected, low-quality or unsafe output, or prompt injection that affects only your own workspace's outputs, unless it lets one workspace read or alter another workspace's data or the Service itself; reports generated purely by automated scanners without validation; and vulnerabilities in third-party services we do not control.

Contact

support@frayme.ai · Frayme Ltd, 15 Carraway Street, Reading, England, RG1 3GB