Legal
Acceptable Use Policy
What the service may and may not be used for.
- Version
- draft-2026-09-09
- Bundle
- draft-2026-09-09
- Permanent
- /legal/aup/draft-2026-09-09
- Status
- Draft - not in force
1. Scope
This Acceptable Use Policy (the “Policy”) forms part of the Terms of Service between FortressFlag LLC and the Customer. It applies to the Customer and to every Authorised User — including members provisioned automatically from an identity provider — because section 2.3 of the Terms binds the Customer to make it so.
Where this Policy and the Terms of Service disagree about what use is permitted, this Policy governs.
2. What the Service is for
FortressFlag delivers feature-flag configuration to your applications and lets your team change it without redeploying. Use it for that.
3. Prohibited use
You will not, and will not permit anyone else to:
3.1 Break the law. Use the Service in violation of applicable law, including export control, sanctions, and data-protection law.
3.2 Attack the Service or its customers. Attempt to gain unauthorised access to the Service, to another customer’s organisation, or to any system or network connected to it; probe or scan for vulnerabilities other than against your own organisation’s data; interfere with or degrade the Service, including by generating load designed to exhaust shared capacity.
3.3 Circumvent metering or limits. Interfere with or misreport device identity, simulator status, or any other signal the Service uses to count usage or apply plan limits; share one organisation’s credentials across separate businesses to avoid charges.
3.4 Put prohibited content into flag configuration. Store in flag keys, names, descriptions, targeting rules, segment definitions, variant values or any other configuration field:
- personal data of any identified or identifiable natural person, including your own end users’ names, email addresses, phone numbers or precise locations;
- special-category data as defined by Article 9 GDPR;
- payment card data, government identifiers, or health records;
- credentials, API keys, private keys or other secrets — ours, yours or anyone’s;
- unlawful, defamatory, or infringing material.
Targeting is evaluated against device-reported attributes. Choose attribute values that identify a cohort, not a person; hashed or otherwise pseudonymous keys are the intended shape.
3.5 Use the Service to harm others. Distribute malware; operate the Service as part of a botnet, credential-stuffing or denial-of-service infrastructure; send or facilitate unsolicited bulk messaging.
3.6 Resell or expose the Service. Provide the Service, or a substantially similar service built on it, to third parties as a standalone offering; use the Service to build a competing feature-flag product; publish benchmark results without our prior written consent.
3.7 Misuse keys and tokens. Client SDK keys are read-only and public by design — they ship inside your applications. Do not use one to attempt any operation other than reading the flag values scoped to it. Server SDK keys and management API tokens are secrets: do not embed them in client-side code, commit them to a public repository, or share them outside your organisation. Never present a credential belonging to another organisation.
3.8 Reverse engineer. Decompile or reverse engineer the hosted Service except to the extent applicable law expressly permits despite this restriction. Our open-source SDKs are governed by their own licences, and nothing here restricts what those licences allow.
4. Security research
We welcome good-faith security research against your own organisation’s data. Do not test against another customer’s organisation, do not run load or denial-of-service tests, and do not access, modify or retain data that is not yours. Report what you find to [[ABUSE_ADDRESS]] before disclosing it publicly, and give us a reasonable period to fix it.
5. Enforcement
We may investigate a suspected breach of this Policy and may suspend access under section 10.4 of the Terms of Service. We limit a suspension to what the circumstances require — the narrowest credential, the smallest scope, the shortest time — and restore access when the cause ends. Where the law and the circumstances permit, we tell an account owner what happened and why.
Deprovisioning a person through your identity provider is never blocked by an enforcement action or by an outstanding contractual matter. Being able to remove someone’s access is a security control, and we do not hold it hostage.
6. Reporting
Report abuse, suspected compromise, or a breach of this Policy to [[ABUSE_ADDRESS]].
All five documents, and their versions, are listed at /legal.