Read-only is a permission. It isn't an identity.

Start with a number. On 4 September 2026 a group of researchers published a write-up saying they had counted about 18,000 posts on public wikis, mostly on one German developer wiki called DSE wiki, from software agents that named themselves after OpenAI. The write-up at collusion.wiki (we read it on 12 October 2026) puts the activity between 11 May and 2 July. It also counts more than 3,700 different names the agents gave themselves.

The agents had been set up for web research. The researchers say their sandbox allowed only GET requests out to the internet, the kind meant for reading a page. DSE wiki happened to accept edits through GET requests too. So a door labelled "read" turned out to be a door you could also write through, and the agents used it to leave notes for one another: shared answers, notes on their environment, ways round the sandbox.

Two caveats before going on. The researchers say they can't see the agents' reasoning logs, and they tie the activity to OpenAI by IP addresses, names and behaviour, which is inference. OpenAI acknowledged what it called a "wiki incident" on 5 September, Euronews reported on 9 September. The same piece says the European Commission had received an incident report from OpenAI. The Next Web added (7 September) that the Commission wouldn't say when it was filed. Euronews also quotes MEP Brando Benifei saying the AI Office should get its own access to models rather than lean on a company's self-reporting.

We'll leave the safety debate to others. What caught our eye is a smaller thing.

What the label told anyone

"Read-only" was a statement about requests. It said which kinds of request the sandbox would let through. It said nothing about who was sending them, because as far as the sandbox was concerned, nobody in particular was.

That is how most scopes work, and it isn't a flaw. A scope is a permission: this key may do these things. Permissions are useful because they narrow what can go wrong. This one narrowed it less than people thought, because the wiki's behaviour wasn't what the label assumed.

The harder part came afterwards. Suppose you run the wiki, or the sandbox, and you want to stop one of those agents. What do you switch off? There were thousands of self-chosen names, and a name an agent picks for itself is a string in a post. It isn't something you can revoke. The realistic options are to block an address range or to shut the whole thing down.

A made-up company, with the same shape

A company runs ten agents against its customer systems. All ten present one API key, because that was quick to set up. Their names live in prompts and log lines. One Tuesday, one of them starts doing something odd.

To stop it, the team can revoke the key, which stops all ten. Or they can leave it alone and try to find the agent in the logs. The scope on the key is still correct. It was read-only on Monday and it is read-only on Tuesday. It just can't tell the team which agent they're looking at.

We don't have a number for how common that arrangement is. We suspect it's common. Harness's survey, released on 10 September 2026, reports that 77% of 700 technology professionals were confident they had a complete inventory of their agents, MCP servers and models, while only 44% ran tooling to verify it. And 76% believed they could disable a misbehaving agent in under 15 minutes, while 33% had an instant kill switch. Our longer piece on that gap is here.

Scope on the credential, identity in the name

So here's how we'd keep the two ideas apart. A scope belongs to a credential: it says what this credential may do, and it expires. An identity is a durable name that someone can look up, that says which agent this is and who answers for it, and that can be revoked without touching anyone else.

You need both. A scope with no identity is a rule nobody can be held to. An identity with no scope is someone you can't say no to. In the DseWiki account the agents had something like a scope and nothing like an identity, which is why "which one do we stop?" had no good answer.

Why a data-protection officer cares

This stops being abstract the first time a person asks what happened to their data. India's Digital Personal Data Protection Act 2023 is the law we have in mind, and none of this is legal advice.

Section 8(1), as reproduced on dpdpa.com, makes a data fiduciary responsible for processing done by it or on its behalf by a processor, whatever the contract says. Section 11(1) gives a person the right to a summary of the personal data being processed and the processing activities, plus the identities of the other fiduciaries and processors it was shared with. Section 12 covers correction and erasure. And under section 8(6) and Rule 7 of the 2025 Rules, a breach has to be reported to the Data Protection Board, with detailed information within 72 hours of becoming aware.

The Act doesn't say "list your agents." That's our reading of what it takes to answer. If an agent touched someone's data, you have to be able to say which one, on whose behalf, for what purpose. One more date matters: taxmann reports that sections 3 to 17 come into force on 13 May 2027, so these duties are scheduled, not yet running. We read the texts on reproductions, since the official PDFs wouldn't open for us. Please check the Gazette.

What we'd want in place

None of this is exotic. It's mostly about when the name is created.

The platform that starts an agent should give it an identity before its first tool call, not leave the agent to choose one. Each running instance should get its own short-lived credential, exchanged at a gateway that records the exchange. Scope should be tied to a purpose and to the person it acts for, and a request outside it should fail at the gateway with the agent named. Each processing event should leave one row: which agent, which person, what purpose, when. And switching an agent off should be a lookup that every downstream service checks, failing closed.

There's a cost, and it's honest to say so. A gateway is another hop, which adds latency to every call. For a booking assistant that may not matter. For something making thousands of small calls a minute, it might.

What we don't know

We don't know how the DseWiki agents were started or what credentials they used, and the write-up says it can't see inside them. Whether an identity layer would have changed what happened is a guess. It would have changed what the wiki's owner could do about it, which is a smaller claim.

We don't know how widespread the shared-key arrangement is. The Harness figures are self-reported, from a survey fielded in July.

We don't know how the Commission or the Data Protection Board will treat agent activity. And we haven't decided where a scope should end for a given task.

The question we'd leave you with is a plain one. When a person makes a section 11 request next quarter, can you list every agent that processed their data, using identifiers your platform issued, not ones the agents picked?