Apify Security Incident: Restrict Storage Without Breaking Your Integrations

Apify is recommending that customers restrict storage access following its November security incident. For teams feeding scraped data into AI agents, the immediate task is to close unintended access while checking that legitimate consumers still work. Rotating a token alone does not fix a storage resource that remains readable by link.

What Apify has confirmed

In its November 13 incident update, Apify says API tokens are now stored as hashes and additional internal protections have been applied. The investigation remains ongoing. Earlier updates attribute account access on November 9 and 10 to a compromised credential and say no further attacker activity had been detected since November 11.

Apify says affected customers have been contacted individually. No notification means the company has not identified that account as affected so far, not that it has proved the account unaffected. Follow the account-specific notice through a trusted route and keep the public incident page as your reference for general updates.

The company also revoked some OAuth connections as a precaution. It has not identified those connections as an attack vector. Do not turn a precautionary disconnection into a claim about the cause of the incident.

Check storage access before changing consumer code

Apify's resource-access guide distinguishes access by resource ID from Restricted access, which requires explicit permission. Individual resource settings can override the account default. Review the runs, builds and storages your workflow uses.

Find General resource access under Login & Privacy in personal Console settings, or Security & Privacy for organizations. Apify recommends Restricted. Changes can take time to propagate, so allow for the documented delay when checking the result.

For a research agent reading an Actor's dataset, record the producer, consumer and access method. Replace reliance on unsigned storage URLs with an authorized path. Do not restore anonymous access just to silence an error.

Separate service credentials from shareable links

The API integration guide recommends a separate token for each service and authentication through the Authorization header rather than a URL parameter. Tokens can be scoped to required resources. Keep them server-side and out of screenshots, support tickets and generated reports.

For the research agent, that means deciding whether it only reads a known dataset or also starts runs and writes output. Give it the permissions its actual workflow needs, then test that workflow. An unnecessarily broad replacement token may restore service quickly while leaving you with a larger exposure than before.

Apify's token rotation flow offers an option to keep the old value active for 24 hours. If you suspect compromise, treat that overlap as a security decision, not a convenient default. Coordinate replacement with the service owner; the old credential remaining usable has a different risk from a brief integration outage.

Restricted resources can still be deliberately shared through signed URLs. The resource-access guide documents both temporary and permanent links, including permanent public URLs for individual key-value store records. Restricted does not mean every previously shared link is harmless. Inventory intended exceptions and avoid putting private output into channels where link recipients should not have it.

Check Actor execution permissions separately

Storage access, service-token scope and Actor execution permissions are different controls. Apify's Actor permissions guide distinguishes limited-permission Actors from full-permission Actors, which can access all account data. Check the Security badge on the Actor rather than inferring its runtime access from the token used by your caller.

An unapproved full-permission Actor can fail with full-permission-actor-not-approved. That is a permission review, not a reason to disable approval prompts. A Store Actor changing from limited to full permissions can also stop a schedule until reviewed. Investigate the requested access before restoring execution.

Verify both denied and intended access

Use a small dataset containing synthetic records for a proposed acceptance check. This is a suggested test, not one I have run:

1. Try the unsigned resource link without an authenticated session. It should not reveal restricted data.
2. Read the same resource through the intended authorized service. Confirm that the expected records arrive.
3. Run the producer once and check its output, then verify the consumer reads the new result rather than an old cached copy.
4. Review the links the workflow places in logs, reports and notifications. Record which are intentionally shareable and who should receive them.

A green Actor run does not prove the downstream agent can read its result, and a working agent does not prove anonymous access is closed. Those are separate checks. Finish the recovery when both match your intended permissions, not when the first error message disappears.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams explain complex platform changes and operational decisions clearly to developers and customers.

Book a 30-minute call