With one customer's token, your AI agent can search another customer's index on a search server that checks only that the token is valid.
Ask your coding agent whether the server matches each token to one customer and accepts that token only for that customer's index.
In this guide, I give each customer a separate index and set up the server to return a 403 error for any search of another customer's index with one customer's token: narsil.sondelali.com/docs/ag…
Do you block AI crawlers from your landing page, or let them in so that ChatGPT can link to your app?
You can embed those documents with a multilingual model on your server through Narsil, an open-source search engine, so that their text stays there: narsil.sondelali.com/docs/em…
Any token in your coding agent's settings is readable by anyone who pulls your Docker image, if your Dockerfile copies every file.
Truffle Security found a working GitLab token in .claude/settings.local.json inside one image, so list **/.claude and **/.cursor in .dockerignore.
Since January 2025, Truffle has found 2,655 working keys in the config files of AI coding tools, against none in 2024: trufflesecurity.com/blog/lau…
Selling your app to teams can make you the person who adds and removes every one of their members by hand.
For example, when a customer emails you to remove a colleague who has left their company, that colleague can still open the team's data until you read the email and remove them.
Let each team look after its members:
→ Give each team one or more owners, who can invite members by email and remove them on the team's settings page.
→ Make the server check on every request that the person who sends it is still a member of the team, and an owner for any invitation or removal.
→ Before you release, check that the server refuses an ordinary member who tries to remove someone, and refuses a removed member's next request.
OWASP's authorization cheat sheet recommends that the server deny access by default and check permissions on every request: cheatsheetseries.owasp.org/c…
Retell AI lets you build voice agents that answer and make phone calls for your app: retellai.com/
When you tell customers about a breach without saying what the attacker took, each of them will have to guess what to change.
On 3 November, for example, mSeven told the customers of its mSecure password manager about 'suspicious activity', and wrote that protecting themselves 'may include changing passwords, resetting or re-enrolling two-factor authentication methods'. So one customer who keeps more than 800 passwords in mSecure asked whether they had to change all of them.
To spare your customers that guess, put these in your breach email:
→ Say how the attacker got in and which data they took.
→ Say what you've changed, such as the keys that you revoked.
→ Tell customers what to do about each kind of stolen data.
mSeven told neither its customers nor The Register whether the attacker reached any customer data: theregister.com/security/202…
ABOUT 40% OF THE PAYMENTS THAT BANKS FLAG AS FRAUD BECOME DISPUTES UNLESS YOU REFUND THEM.
Stripe writes in its guide to disputes: 'If you don't refund the charge, about 40% of Visa and Mastercard EFWs become fraud disputes (the rate varies by card network and payment amount).'
Refund each flagged payment that is no larger than your dispute fee, which Stripe charges at $15 in the US and keeps even when you win the dispute.
Will you refund every small flagged payment as soon as Stripe warns you, or wait to see whether the cardholder disputes it?
If your AI agent keeps what it learns only inside the conversation, a customer will have to tell it again in every new session what they told it in the last one.
Ask your coding agent which table stores what your AI agent learns about each customer, and whether a new session loads those rows before your AI agent replies.
In the guide that I've linked in the first comment, I divide an agent's memory into three parts: the plan for its current task, a record of every message and tool call, and what it learns about each person.
Your AI agent has to write what it learns to a database, because the next session can load only the rows that the session before it wrote: sirannon.sondelali.com/docs/…
Is it time to launch once a stranger can pay without your help, or do you keep polishing screens while you earn nothing from the app?
Narsil is an open-source search engine that can match a misspelled word to the right one, whether you embed it in your Node.js app or serve it over HTTP: narsil.sondelali.com/docs/fu…
In an app that a team shares, the second person to save a record can wipe out the first person's changes without either of them seeing an error.
For example, one of them changes a client's phone number while the other fixes the address. If the app saves the whole form each time, it will write the old phone number back along with the new address.
Before you release:
→ Ask your coding agent to give each record a version number, so that the server can refuse any save made from an older version of the record.
→ Open one record in two browsers, save a change in each, then check that the second save fails with a message that asks the user to reload.

ALT Under the heading 'When both teammates save, the app keeps only the second save', three cards show one client record. In the first card, both teammates open it with the old phone number and the old address. In the second, teammate 1 saves a new phone number. In the third, teammate 2 saves a new address, so the card shows the old phone number again, in blue.
On MDN's page about the If-Match header, you can read how a server refuses a save that would overwrite a change that somebody made after the user opened the record: developer.mozilla.org/en-US/…



