Anthropic ID verification: splitting agents in 16 days

On 11 June at 09:14, the operations lead at a 23-person wholesaler in Tiel forwarded us an Anthropic email and asked what 8 July meant for the fourteen agents we had built her. Ten of them read inbox threads, look up product specs in a knowledge base, draft replies, and never touch the outside world. Four of them do real work — a computer-use agent that drives an old Citrix VDA to update price lists in the ERP, a code-execution agent in a Modal sandbox that reconciles shipment manifests, a file-access agent that lives in their SharePoint tenant to keep order PDFs organised, and a Playwright-driven browser agent that books pallet pickups on a carrier portal that has no API.

The email said that from 8 July 2026, anyone calling the high-capability API features — the same four things we just listed — has to complete identity verification on the workspace. The verified person becomes a named party for that traffic. The full text of the policy lives at anthropic.com/legal.

If we verified an ABN employee against the existing client workspace, that workspace's data-processing agreement would have a new sub-processor attestation in scope. Every customer DPA the wholesaler had ever signed — and they had signed a stack — would, on a strict reading, need an addendum. The legal team would not love us.

We had sixteen days. This is what we shipped. It works whether you have four agents or forty, specific enough that you can lift the architecture, generic enough that you can swap Citrix for Azure Virtual Desktop and SharePoint for Google Drive without changing the shape.

What ID verification actually changes

ID verification only attaches to the workspace that calls the gated capabilities. If a workspace never invokes computer-use, code-execution with network, file-access with tenant scope, or browser-control with screenshot, it stays in the previous regime. The inbox-RAG agents read text and write text. They trigger nothing.

So the question is not do we verify. The question is where the verified identity lives, and whether it appears anywhere in the data-processing chain of an existing contract.

For us the answer was: build a second workspace, verified, owned by an ABN entity rather than the client, invoked over a service boundary. The client's existing workspace stays the front door for the ten inbox agents and forwards specific tasks to the second workspace as needed. The second workspace processes nothing that was not already covered by the original DPA's ABN BV as sub-processor with right to engage further sub-processors under equivalent terms clause.

That clause is the load-bearing one. If your DPA does not already give you room to engage further sub-processors under equivalent terms, this playbook will not save you the re-sign. You will have a conversation with the client's DPO first. Check before you write any code.

The split, drawn out

We drew it on a whiteboard with two boxes. The client wanted to see it before they signed off, so we tightened the boxes into a one-page diagram and put it in the project repo.

Workspace A — tiel-prod — stays where it always was. Anthropic billing on the client's invoice. Ten agents. Inbox triage, knowledge lookups, draft replies, FAQ chat for the front-of-site. No verified identity attached.

Workspace B — tiel-cap — is new, billed to ABN, verified to a director's ID under the ABN BV legal entity. Four agents. Computer-use, code-execution, file-access, browser-control. Each one sits behind a thin HTTP service that workspace A can call.

The call shape we settled on:

POST /agents/file-access/move-pdf
Authorization: Bearer <hmac-signed-token>
Content-Type: application/json

{
  "tenant_id": "tiel",
  "task_id": "ord-2026-07-44823",
  "intent": "move shipment PDF to /Orders/2026/Q3/"
}

Workspace A holds no credentials for SharePoint, the Citrix VDA, Modal, or the carrier portal. It has one outbound secret, the HMAC key for the agent gateway. The gateway authenticates, routes to the right capability agent in workspace B, and returns a structured result to workspace A.

That gateway is a 200-line Cloudflare Worker. Inbound from workspace A only, outbound to the four agent endpoints, Logpush sink shared with both workspaces. We will come back to the logs.

DPA chain, untouched

The contract chain on day one, before this work, was: the wholesaler as controller, ABN BV as processor named in 100% of their customer DPAs, Anthropic as sub-processor named in 100% of their customer DPAs, and Modal, Cloudflare and Microsoft (for SharePoint through the client's own tenant) listed in the sub-processor schedule that the wholesaler's customers had signed off on.

After the split, the contract chain is identical. The new workspace tiel-cap is owned by ABN BV. The verified individual is an ABN BV director. No new legal entity appears in the data-processing chain. Anthropic's role for tiel-cap is a stricter version of the role it already played for tiel-prod — the same sub-processor, with additional identity attestation on ABN's side.

The verified identity attaches to ABN, not to the client. The wholesaler's customers never had a relationship with that identity. They do not need to be told about it any more than they need to be told who at ABN wrote which line of Python.

We wrote a short memo to the client's DPO explaining all of this in plain Dutch. The memo did not require a counter-signature. We filed it in their compliance folder and moved on.

Short-lived credentials for the browser agent

The Playwright agent — headless Chromium on Modal, driving the carrier's pallet-booking portal — needed its own twist. The carrier has no API. Login is human-only. So the agent had been logging in as a real human user, a service account we created in 2024 for that purpose.

That worked. It also meant a high-capability agent held standing credentials to a real account, a posture that ages badly the moment a verified identity is attached upstream.

When we re-architected, we moved that agent to short-lived sessions. Each booking task issues a fresh credential at the start, uses it once, rotates it at the end. Cloudflare published a pattern for this in June for AI agents specifically: temporary accounts for AI agents, which ranked 225 on Hacker News the week we shipped. The idea is that the agent never holds a long-lived password; the credential exists for the duration of the task and is then gone.

We cannot do exactly that against the carrier portal, because the carrier portal does not issue temporary credentials. So the rotation happens on our side. Vault stores a sealed seed. The agent gateway derives a one-time login that is valid for the next eight minutes. The agent uses it, the portal session is closed, the password is rotated again before the next task. The blast radius of a compromised agent is one shipment booking attempt, not the entire account.

It is not the cleanest design. It is the cleanest design we could ship in sixteen days against a carrier that will not change.

Audit logs that survive the split

The original setup logged everything to one stream. After the split, we had a real risk of losing the through-line: a customer reply drafted by an inbox agent might trigger a price-list update by the computer-use agent twenty minutes later, and we needed to correlate them on demand.

Every request from workspace A to the gateway carries a task_id that propagates into workspace B. Both workspaces ship logs to the same Logpush sink, keyed on task_id. A single LogQL query joins them.

{job="anthropic-audit"}
  | json
  | task_id = "ord-2026-07-44823"
  | line_format "{{.workspace}} {{.agent}} {{.event}}"

That query is what the operations lead now opens when a customer asks what the system did with their order. Two workspaces, one log, one answer.

We pinned a retention policy to the gateway: full request and response bodies for 90 days, structured metadata for 24 months. That matched the wholesaler's existing data-retention notice. No privacy-policy update required.

Anthropic-side hygiene before 8 July

The build is the easy part. The Anthropic-side setup has two gotchas worth naming out loud.

First, when you create the new workspace, the API keys in workspace A keep working. Nothing about that workspace changes. Resist the urge to tidy up by reissuing keys. You do not need to, and reissuing introduces a window where the inbox agents stop working for no reason your client will accept.

Second, complete the identity verification at least 72 hours before the deadline. We did ours on 17 June, five days after the original email landed. The verification asked for a passport photo, a live selfie, and the legal-entity registration extract. It came back approved the next morning. If it had failed and we had needed a manual review, doing it on 7 July would have been a bad idea.

Anthropic's engineering team published a piece worth reading alongside this: building effective agents. The points about each agent owning its own credentials rather than inheriting yours map cleanly onto the split described above.

Monday morning at the client

Nothing visible. That was the goal.

The inbox agents continued to triage. The price-list agent continued to update prices. The pallet-booking agent continued to book pallets. Latency on cross-workspace calls added roughly 280 ms to the four high-capability flows, which no one noticed because they all run async and report back through Teams.

The operations lead got one new dashboard tile — a count of gateway calls per agent per day — which she said she would ignore for the first week and then started checking every morning by the second.

Where this playbook stops

Three situations where the shape changes.

Your DPA does not already cover sub-processor engagement under equivalent terms. Then you renegotiate, and the architecture above is half a solution.

Your client's regulator (financial services, healthcare, certain public-sector tenders) requires that the controller see the identity of every named individual processing data. Then you cannot hide the verified person inside a sub-processor. The individual has to be named upstream, and you take the re-sign.

Your high-capability agents need direct access to data that the inbox agents have already loaded into context. Then the gateway is not a thin service — it brokers data movement, and you are writing a small data layer. Budget two weeks, not a weekend.

For the wholesaler in Tiel, none of those applied. The split was clean.

When we built the gateway and the verified workspace for that wholesaler, the load-bearing decision turned out to be the DPA review on day one, not the Cloudflare Worker or the Modal sandbox. If your sub-processor clause already gives you room to engage further parties under equivalent terms, you have a weekend's work ahead of you. We do this kind of AI agent separation work end-to-end when the deadline is real and the calendar is short.

Open your three most-signed customer DPAs and search for sub-processor and equivalent terms. The answer is in those two phrases. If they are missing, that conversation is the first one to schedule today.