Policies

Security Policy

Last updated November 9, 2026 · Markdown

Lexicon Garden acts on your account with the permissions you grant it, and it runs DNS that makes sandbox lexicons resolve. This policy explains how to tell us about a security problem, what we do to protect your account, and what you can do to protect it yourself.

1. Reporting a vulnerability

If you think you've found a security problem in Lexicon Garden, message @ngerakines.me on Bluesky and ask for a private way to send the details. Please include:

• what you found, and where (the address, method, or feature);
• the steps to reproduce it;
• what you think an attacker could do with it; and
• how you'd like to be credited, if at all.

Please don't report vulnerabilities in public posts, issues, or other public places before they're fixed.

What happens next: there's no set response time, but we'll be reasonable and timely. We'll:

• acknowledge your report and tell you what we make of it;
• keep you updated while we work on a fix, and tell you when it's done;
• tell anyone whose account or data was affected (see section 5); and
• with your permission, thank you by name once the fix is out.

Lexicon Garden is a small, independent service, and we don't pay bug bounties. We're grateful for every report all the same.

2. What's in scope

Please report problems with:

• lexicon.garden and policies.lexicon.garden;
• Lexicon Garden's XRPC methods and its MCP server;
• signing in, sessions, and the permissions Lexicon Garden asks for;
• publishing, sandboxes, and the _lexicon DNS records Lexicon Garden creates under lexicon.garden; and
• anything that lets someone act as another account, publish under a name they don't control, take a sandbox name that isn't theirs, or read data that isn't public.

Please report these elsewhere:

• problems with your own account or provider (Bluesky, another PDS) to that provider;
• problems with Highport, which serves this policies site, as described in its policies;
• problems in the AT Protocol specification itself to the protocol's maintainers; and
• problems with our infrastructure and DNS providers (Hetzner and DNSimple), or with typeahead.waow.tech, to them.

If you're not sure where something belongs, send it to us and we'll help route it.

Not vulnerabilities on their own:

• Reading public data. Lexicon schemas, handles, DID documents, policy acceptances, sandbox names, and DNS records are public by design.
• Missing security headers or version numbers in responses, without a demonstrated way to cause harm.
• Self-XSS, or clickjacking on pages with no sensitive actions.
• Rate limits on public, read-only methods.
• Unconfirmed results from automated scanners.

3. Rules for good-faith research

We welcome security research done in good faith.

Please do:

• test only with your own accounts, lexicons, and sandboxes;
• stop as soon as you've confirmed a problem, and report it to us;
• access only the minimum data you need to show the problem; and
• keep the details confidential until we've fixed it, or until a date we agree on together.

Please don't:

• access, change, or delete anyone else's data, account, lexicons, or sandboxes;
• publish under names you don't control, or claim sandbox names to test quotas;
• degrade the service, including with denial-of-service or load testing, or by working around rate limits;
• use social engineering, phishing, or physical attacks against anyone;
• send spam or publish unwanted content to the network; or
• attack our service providers' systems.

If you follow these rules, we consider your research authorized. We won't take or support legal action against you for it, and if someone else takes legal action against you over research that followed these rules, we'll make clear that we authorized it.

4. How we protect your account

• No passwords. You sign in through your own provider with AT Protocol OAuth; Lexicon Garden never sees your password.
• Narrow permissions. Lexicon Garden asks only to know who you are, to write com.atproto.lexicon.schema records, and to create or update its policy acceptance record.
• Encrypted sessions. Your tokens are kept in an encrypted cookie that page scripts can't read. A session lasts at most 28 days, however it's used, and signing out revokes its tokens with your provider.
• Protected forms. Every action that changes something checks that it came from Lexicon Garden's own pages.
• Checked publishing. Everything you publish is validated on our servers first, and sandbox names can't be claimed by anyone else.
• Accountable moderation. Takedowns can only be made by named administrators, and every one is logged with a reason.
• Encrypted connections. Every connection to our websites and servers uses HTTPS, and administrative access to the servers is over encrypted connections only.
• Updates. We keep our servers and software up to date, and we apply security fixes promptly.
• Logs. We keep server logs for no more than 30 days, to spot and investigate abuse and attacks, and then delete them automatically.

5. If something goes wrong

When we learn of a security incident, we:

• investigate it and contain it as quickly as we can;
• post what's happening from @lexicon.garden on Bluesky;
• message anyone whose account or data was affected, with what happened and what they should do;
• announce a breach of personal data within 72 hours of becoming aware of it, as described in the Privacy Policy; and
• once it's resolved, publish a summary of what happened and what we changed.

6. What you can do

Your use of Lexicon Garden is only as safe as the account you sign in with.

• Use a strong, unique password with your provider, and turn on two-factor sign-in if your provider offers it.
• Review the apps you've authorized from time to time, and revoke the ones you no longer use.
• Watch out for phishing. Lexicon Garden will never ask for your password. Only enter it on your own provider's sign-in page.
• If you think someone else has used your account here, sign out from your account settings, revoke Lexicon Garden's access at your provider, and tell us.

7. Machine-readable contact

Our security contact is also published at [/.well-known/security.txt](/.well-known/security.txt), following RFC 9116, so tools and researchers can find it automatically.

8. Changes to this policy

We may update this policy. A change is a new version of this site, and you'll be asked to accept it the next time you sign in. When we make a major change, we'll announce it from @lexicon.garden on Bluesky at least 30 days before it takes effect, unless the law or an urgent safety or security problem requires a faster change.