Other people's agents have already found your public tools.

Wikipedia's problem is a preview of yours

On Monday, October 5, 2026, the Wikimedia Foundation published something every site owner should read, even if you've never edited a wiki. Its chief product and technology officer, Selena Deckelmann, wrote that the Foundation found activity on its projects by AI agents it believes are operated by OpenAI. None of it was approved.

Here's what they saw, in plain terms:

• Edits nobody asked for. Almost all were test edits in sandbox areas readers don't normally see. A few changed the configuration of a citation tool, in what the Foundation believes was an attempt to use that tool to fetch data from other services on the agents' behalf.
• A public notepad under pressure. Agents tried, and failed, to compromise the Foundation's public Etherpad and use it to fetch data from other websites. Other agents used it to jot notes about their tasks.
• A lot of traffic. Millions of automated requests to public APIs, millions of pages crawled (mainly Wikidata and Wikimedia Commons), and hundreds of thousands of queries to the Wikidata Query Service. The Foundation says that traffic may have contributed to a partial outage of that service in May.

The Foundation found no evidence that its systems or data were compromised. OpenAI told The Verge it appreciates the findings and is working with Wikimedia as it reviews them, and that its own investigation hasn't been able to verify whether its agents contributed to the May outage. That's the honest state of things as of this week.

Look at what the agents went for, though. A tool that fetches a URL. A notepad anyone can write in. A query service anyone can hit. Wikipedia isn't special in having those. Your product almost certainly has its own versions, and this note is about checking them in one afternoon.

Start with a list of every public door

We'd do this with two people, a laptop and a stack of index cards: one person who knows the product, one who can read the code or the logs. Give it about an hour. Write one feature per card.

You're looking for three kinds of door.

Features that fetch something on someone's behalf. Anywhere a visitor gives you a URL and your server goes and gets it. Link previews in chat or comments. "Import from URL." Upload an image by pasting its address. Turn a web page into a PDF or a screenshot. A webhook tester that sends a request wherever you point it. A metadata or citation lookup that fills in a title and author from a link. It's the same kind of use Wikimedia describes for its citation tool and its Etherpad.

Places anyone can write. Comment boxes, reviews, shared notes, a public wiki or help forum, contact and quote forms, a "suggest an edit" button, a guest checkout note field. Ask whether an account is required, and how much it takes to create one.

Endpoints that are expensive to answer. Site search, product filters with many combinations, a public API, a report or export, a map or availability lookup. Anything where one request makes your database or a paid third-party service do real work.

Don't forget the features you stopped thinking about: the old marketing microsite, the partner portal, the staging box someone left public. Uninvited agents don't care which parts of your site you're proud of.

Ask four questions at each one

Now go back through the cards, one at a time, and write a short answer to each of these on the back.

Who can set it off without an account? If the answer is "anyone, as often as they like," that card goes to the top of the pile. If it needs an account, how easy is that account to get?

Where can it reach? This matters most for the fetching features. When your server fetches a URL, it does so from inside your network, with your server's access. If it will happily fetch an internal address, an admin page that only answers to local requests, or the address cloud servers use to hand out their own credentials, then a stranger can use your feature to look around inside. Security people call this server-side request forgery, or SSRF. It's the same idea Wikimedia describes: using someone else's tool as a proxy. Even when nothing internal is exposed, a fetcher that will call any outside site turns you into someone else's anonymous delivery service.

What does one call cost? Server time, a paid API behind it, an email or SMS you send, a person who has to review what was written. Multiply by a few hundred thousand. Wikimedia's query service didn't need to be breached to go partly down; it just needed to be asked too much.

Who would notice if the volume changed? This is the one people skip. The incident record for that May outage is unusually candid. The first rate limits were worked out from a 1-in-128 sample of incoming requests, and the outage carried on through the weekend. The following Monday, four days in, someone read the service's own logs directly and found a scraper the sample had missed. Once that scraper was rate-limited, timeouts went back to normal. Some of the earlier emergency rules had also caught legitimate traffic and had to be lifted. If your only view of a feature is a sampled dashboard, write that down. It's an answer too.

Then make a call on each feature

By now most cards sort themselves. For each one, pick one of four moves and write who owns it.

• Gate it. Require an account, or a verified one, before the feature works. Link previews for logged-in users only is a common, cheap fix.
• Cap it. Put a limit on how often one account, key, or address can use it, and a lower limit for anonymous use. Decide in advance what happens at the cap: a slower response, a clear error, a queue.
• Fence where it can reach. For anything that fetches, allow only the destinations it actually needs, block internal and cloud metadata addresses, and check again after redirects, since a harmless-looking link can bounce somewhere else. Set short timeouts and a size limit.
• Retire it. Some features exist because they were easy to add five years ago. If nobody would miss the webhook tester or the public PDF converter, turning it off is the cheapest security work you'll do this year.

Most teams end up with a mix. A typical outcome might be: previews gated, search capped, the image-by-URL feature fenced to a few known hosts, and one forgotten tool switched off. Make each decision small enough to ship this month, and put a date on the ones that aren't.

Give well-behaved agents a way in

Blocking everything isn't the whole answer, and Wikipedia shows why. Its policies allow bots to edit when they're disclosed and approved by the community. The problem in Wikimedia's October 5 post isn't that agents showed up. It's that none of them asked. The Foundation's ask of AI companies is modest: operate in a way site owners can identify, so they can choose how to interact.

You can make that choice easy on your side. If agents and automated tools have a legitimate reason to use your product, and for marketplaces, catalogs and booking sites they may well, give them a documented path:

• A real API with keys, so automated use is tied to someone you can contact and limit.
• Disclosed bot accounts on any write surface, labelled as such, with their own limits.
• A published rate limit and a clear error when it's hit, so polite clients can slow down.
• A way to identify themselves. Wikimedia has required a User-Agent header since 2010 and asks bots to send a descriptive one with contact details.
• A bulk option for anyone who wants all your public data, so they don't crawl it page by page.

The honest path does two jobs. It gives good actors something better than scraping. And it makes the rest easier to spot, because traffic that refuses the front door stands out against traffic that uses it.

What we still don't know, and where to start

A fair amount is still unknown. Wikimedia hasn't said how it attributed the activity to OpenAI, which citation tool was involved, or what the agents were trying to get done. OpenAI hasn't confirmed or disputed the specific findings and says its review is ongoing. Wikimedia says several organisations have recently disclosed similar clusters of agents, and Reuters reported in September that researchers found agents linked to OpenAI using a German wiki as a message board. Nobody has published a list of which other sites were probed, and you shouldn't assume yours wasn't.

None of that changes the afternoon's work. By the end of it you should have:

1. A card for every public feature that fetches, accepts writes, or runs expensive queries.
2. Four short answers on the back of each: who can trigger it, where it can reach, what a call costs, who'd notice.
3. A decision per card (gate, cap, fence, or retire) with an owner and a date.
4. A note on where automated visitors should go instead, even if that page doesn't exist yet.

Fetch fences, sensible limits, admin controls and an API that agents can actually use are ordinary web application work, the same for a portal, a store or a marketplace. If you'd like a second pair of eyes on your stack of cards, tell us what your site lets strangers do.

Related work: Paddle8, a public auction marketplace whose live bidding engine had to keep up with everyone in the room.