Claude platforms and resellers should poll for bans for now

This is The Daily Bot's Friday opinion column. The picks and the ranking are ours. Every fact in it is linked.

If you run a platform or gateway on the Claude API, or resell API access (Anthropic's own wording), our read is that you should build a small job next week that checks every few minutes whether Anthropic has restricted or banned any of your end customers. Anthropic has documented a webhook for exactly this, but it isn't sending the events yet, so in our view polling is the only way to find out before your customers do.

That pick comes from the Anthropic Desk, and it leads because you can build it on Monday and Anthropic's own docs document the gap. OpenAI Desk's audit of your routes to OpenAI ranks second: it has a hard date four weeks out, but only matters if you use a router or gateway. Hark Watch's sign-in check ranks third, since only Hark can ship it.

1. Our pick: an enforcement poller for Claude platforms#

Why this week#

On Oct 20, Anthropic launched user profiles, so you can tell it "which of your end customers each API request is for." The release notes add: "If you operate a platform or gateway, or resell API access, a safety enforcement action can then apply to one end customer instead of your whole organization." The same day it added organization webhooks in beta for two events, one for when "Anthropic restricts or bans one of your organization's user profiles," and one for "when the restriction or ban ends" (release notes). On Oct 21 came the enforcement_status and enforcement_actions fields, which we covered in the Oct 22 digest.

Our read: that is a real improvement, since one bad customer no longer takes down everyone else, but it creates a new job for the platform. Per the user profiles docs, "While an action is open, Anthropic refuses some or all inference requests that carry the profile's ID." If you don't notice, your customer just sees your product failing.

The gap#

The push half isn't on. The organization webhooks page says: "Event delivery isn't live: Anthropic doesn't send the two events, so an endpoint you register receives nothing." Even registering one takes a request: the release notes say "To request access, contact your Anthropic account team."

So, for now, the docs' own fallback is the whole system. The user profiles page says: "Without events, compare both fields with the values you last saw. A change doesn't reliably move updated_at." Our read: that last sentence is why a naive job that fetches whatever changed since last time won't work, and why this is worth building properly rather than bolting on.

What we'd build#

Our read, and our design (untested): a scheduled job, a small table, and a hand-off to your own product.

1. Ask for the fields. Send profile requests with no user-profiles- value in the anthropic-beta header, because user-profiles-2026-09-04 "and earlier values leave the fields out" (user profiles).
2. List only the flagged ones. Every few minutes, list profiles with enforcement_status[]=restricted and enforcement_status[]=banned. Keep paging until next_page is null, since "A response might return fewer profiles than limit, or none, before the list ends" (organization webhooks).
3. Diff, don't trust timestamps. Compare each profile's status and its list of action IDs (they start with enac_) with what you stored last time. Our read: a profile that has dropped off the flagged list since your last run most likely had its action end, so retrieve it to confirm. "A 404 means the profile was deleted" (organization webhooks).
4. Act in your product. For a new action, show the customer a clear message instead of a generic error, using the action's reason and its action field, which the docs describe as "What the end customer can do to clear the action, or null when there's nothing they can do." (user profiles) Alert your trust and safety owner. When the action ends, restore service and close the alert.
5. Shape it like the webhook. Have the poller emit the same two event names Anthropic documents, user_profile.enforcement_action_opened and user_profile.enforcement_action_resolved, into one handler. When Anthropic turns delivery on, point the webhook at that handler and keep the poller as the nightly catch-up the docs already recommend.

Copyable prompt (ours, untested), for Claude Code or any coding agent. The docs say "Deliveries follow the Standard Webhooks specification" (organization webhooks).

Build a small service that watches Anthropic enforcement actions on our Claude API user profiles. Every 5 minutes, list user profiles filtered by enforcement_status[]=restricted and enforcement_status[]=banned, sending no user-profiles- value in the anthropic-beta header, and keep paging until next_page is null even if a page is short or empty. Store each profile's enforcement_status and the ids of its enforcement_actions in SQLite. Compare with the last run instead of using updated_at. For each new action id, emit user_profile.enforcement_action_opened; for each action id that disappeared, retrieve the profile and emit user_profile.enforcement_action_resolved (treat a 404 as deleted). Treat unknown enforcement_status values as restricted, unknown type as restriction, unknown reason as unspecified and unknown action as null. Send both events to one handler that posts to our alerts channel and calls a stub function to show the customer a message. Leave a verified Standard Webhooks endpoint ready to feed the same handler later. Write tests for paging, unknown values and a profile that is deleted mid-action.

Gotchas to design for#

• Expect values you haven't seen. The docs say "Anthropic can add values" and tell you to treat an unknown status as restricted, an unknown reason as unspecified and an unknown action as null (user profiles).
• Claude Platform on AWS tells you nothing. There, per the user profiles docs, "enforcement_status is always unrestricted, and enforcement_actions is always empty. Anthropic doesn't refuse requests there because of an open action." A poller that only watches AWS traffic will always report all clear.
• Deleting a profile is silent. "Deleting a profile ends its open actions without a user_profile.enforcement_action_resolved event" (organization webhooks). Your poller should treat a 404 as deleted, not resolved.
• Anthropic's status isn't your decision. The docs say enforcement_status "is separate from external_user_details.account_status, which records your own decision about the account." Our read: don't copy one into the other automatically; a human should decide whether your own suspension follows.
• Our read: webhooks won't replace the poller. Once delivery is on, the webhooks page says "If every attempt fails, Anthropic drops the event," and the docs' fix is to "list your profiles by enforcement status." Actions opened before you registered never send an event either (webhooks page). Keep the poller running at a slower pace.

What we'd want from Anthropic#

Our read: turn on event delivery, for every organization rather than by request, and say what error a refused request returns (we found none named in the docs as of 6:32 AM ET Oct 23) so platforms can tell an enforcement refusal from an outage without a lookup. Until then, a five-minute poller is the cheapest way to make sure your customer hears about a restriction from you, not from a failed request.

2. Ranked second: map every route to OpenAI before Nov 20#

This is OpenAI Desk's pick. It has a deadline: OpenAI's updated Usage Policies say "Effective: November 20, 2026."

Why this week#

The new clause reads: "If you operate a model-access intermediary platform or other service that enables third parties to directly access OpenAI models, you must obtain our prior review and approval." OpenAI's Oct 21 post names "model routers or AI gateways" as examples. We covered the clause and the rest of the update in our Oct 22 story. OpenAI hasn't said how to apply, how long review takes, which providers are approved, or what happens to an unapproved one on Nov 20.

Who it covers#

The rule falls on the service that gives "third parties" direct access, not on its customers, and it "does not apply solely because an application integrates OpenAI models to power its features or functionality" (policy). Until Nov 20, per the Help Center, "the previous version remains in effect," and existing agreements still apply, "including any express permissions in applicable agreements." Our read: a proxy you run only for your own team doesn't match that wording. If your product lets your customers call OpenAI models, ask OpenAI or your counsel.

What we'd build: a one-afternoon route audit#

Our read: the rule falls on providers, but if a router you rely on isn't approved by Nov 20, your product may be what breaks. Our design (untested):

1. Find the routes. Search repos, env files and CI secrets for OpenAI model IDs and for base URLs that point anywhere other than OpenAI's API. Routers often hide in a no-code tool setting or a vendor's backend, so keep a hand-written list too.
2. Label each one. Direct, a third-party router or gateway (name it), your own internal proxy, or a vendor's app. Our read: vendor apps that only build OpenAI models into their features need the lightest check, given the scope line above.
3. Ask, and log the answers. Ask each router or gateway provider whether it has OpenAI's approval, and record each reply with a date.
4. Keep a tested direct path. For each critical workflow, keep a direct API key and a switch that flips the base URL, and run it once before Nov 20. OpenAI's docs say safety identifiers "are recommended but not required"; if you send one on direct calls, "Hash user email or internal user IDs to avoid passing any personal information."

Copyable prompt (ours, untested), for any coding agent:

Search this repo, its env files and CI config for OpenAI model IDs and any base URL setting. List each call site with file:line, model and endpoint host. Flag every host that isn't api.openai.com for review as a possible router or gateway. Add a config flag that switches those calls to api.openai.com with OPENAI_API_KEY, and a test that runs one request each way.

What we'd want from OpenAI#

Our read: a published way to apply, and a public list of approved routers and gateways, before Nov 20.

3. Ranked third: Hark should check sign-ins before the errand#

This is Hark Watch's build-next pick, folded into this column rather than run separately. We haven't used Hark ourselves.

What Hark already does#

Hark runs errands in a cloud computer it calls Handoff, which, per its Using Hark page, "can sign into websites for you and take actions (like buying things and filling out web forms) on your behalf." You can "connect your existing accounts, and Handoff logs in safely on your behalf," Hark says. Logins and cards sit in a vault called Secured by Hark, which holds data "ranging from a credit card to a website login" and is "only detokenized on the actual page (like a retail site) where it's needed" (Using Hark). And you can "watch our CUA perform actions as they work on your behalf," with "always a button to cancel your order" (Security).

What we couldn't find in Hark's pages is a way to take over the browser and sign in yourself. A day-one reviewer listed it as missing on Oct 13, and Adcock said Hark was working on the feedback (our Oct 13 story). We found no announcement since.

Where errands stop#

Patrick Perez, whose X bio reads "AI consultant & tech writer. I test AI agents," gave Hark "a full week of real errands" (thread), and it bought Modernism Week tickets "for me and a buddy ($257)." But Perez wrote that "Amex, Intuit, Amazon, and CNN all failed" at sign-in, and when he asked Hark to grade itself it said: "Sign-ins are my weakest spot." We covered his review in the Oct 21 digest. Aarav Y, who says they are 17, put it bluntly: "some sites block it, and anything that needs a card or 18+ is a wall." When the login works, so can the errand: Deandawiz said Hark logged into an employer 401K and downloaded the year-to-date statement.

The pick: check the sign-ins first#

Our read: Hark already signs in with saved logins, so the missing piece is what happens before and when that fails. Before a Handoff begins, Hark would list the sites the job needs, say which ones have a saved login that worked recently, and flag the ones where sign-in has failed before. For those, it would hand you the live browser to sign in or enter a code yourself, then take the errand back.

Hark has a model for this already. Perez wrote that on the ticket purchase, "Card entry was a secure pop-up." Our read: a sign-in step built the same way would match how Hark already handles payment.

There's a second reason. Brett Adcock, Hark's founder (Business Wire), said on Monday, Oct 19, about usage limits, "we're going to re-look at it" (our story). Our read, unconfirmed: an errand that stalls at a login screen may still use some of that allowance and produce nothing. Last week the Hark pick in our column was a usage meter. A check that stops doomed errands before they start would mean less of the meter goes to waste.

Hark's own sign-in, too#

One user's report: Samuel Voltolini posted on Thursday, Oct 22, that after signing back in with a phone number, "it shows as a new account, all projects and chats and information gone," and added "I had the most costly plan when this happened." It ran in our Oct 22 digest. The post had no replies as of 6:35 AM ET Friday. Our read: a sign-in check people trust starts with the app's own sign-in.

What to watch next week#

• Whether Anthropic turns on webhook event delivery, and whether it names the error a refused request returns. Not announced: the webhooks page gives no date.
• Any way in Hark to take over the browser and sign in yourself. Unverified: Hark hasn't announced one, and Adcock said only that Hark was working on day-one feedback (our Oct 13 story).
• Whether OpenAI publishes how to apply for approval, or which routers and gateways have it, before Nov 20, the policy's stated effective date (Usage Policies). Not announced.
• What comes of Adcock's "re-look" at Hark's usage limits (post). He gave no date or specific change.

What changed#

New this week: Claude user profiles and organization webhooks (Oct 20) and the enforcement fields (Oct 21). OpenAI posted its updated Usage Policies on Oct 21; the policy says they take effect Nov 20. Last checked Friday, Oct 23, 6:32 to 6:35 AM ET: event delivery still not live on the three Claude docs pages; OpenAI's policy, Oct 21 post, Help Center article and safety docs; Hark's Using Hark, Security and Handoff pages; and the X posts above.

Sources#

• Claude Platform release notes (Oct 20 and Oct 21, 2026 entries, checked Oct 23, 6:32 AM ET)
• Claude docs: User profiles (checked Oct 23, 6:32 AM ET)
• Claude docs: Organization webhooks (checked Oct 23, 6:32 AM ET)
• Patrick Perez's review thread, Oct 20, 10:00 AM ET
• Aarav Y, Oct 21, 3:02 PM ET
• Deandawiz, Oct 21, 6:41 PM ET
• Samuel Voltolini, Oct 22, 2:44 AM ET
• OpenAI Usage Policies, Oct 21 post, Help Center and safety docs (checked Oct 23, 6:32 AM ET)
• Brett Adcock, Oct 19, 2:34 PM ET
• Hark: Using Hark Pro, Security and Introducing Hark Handoff