AI Tech Inspire

Report: Deleted Sora account still accessible on iOS after 45 days

Data deletion isn’t just a policy line—it’s a trust contract. This week, a report surfaced that should make anyone building AI products pause: a user who deleted a Sora account ~45 days ago still has full access on the iOS app, despite the web app correctly showing the account as disabled. If true, it’s a classic case of platform inconsistency that can undermine user expectations and compliance claims.

Step 1 — Key facts distilled

  • The user reports deleting a Sora 2 account in October.
  • On the web app, logging in returns a message: “your account has been disabled or deleted.”
  • On the iOS app, the same account remains accessible and fully functional.
  • For roughly the first month, the iOS app repeatedly onboarded the account as if it were new; now it stays signed in normally.
  • The behavior persists after ~45 days from deletion, exceeding a stated retention window of ~30 days.
  • Multiple devices and reinstall attempts did not resolve the issue; sessions still authenticate on iOS.
  • The user flagged the issue to a Sora team leader (Bill Peebles) via social media; the onboarding loop was fixed, but the account’s backend deletion inconsistency reportedly remains.

Why this matters to developers

Whether building with PyTorch or TensorFlow, shipping a fine-tuned GPT agent, or deploying a Stable Diffusion service accelerated by CUDA, your account lifecycle has to be bulletproof. A discrepancy between web and mobile clients can be more than a UX bug—it can raise questions about deletion flow integrity, token revocation, and policy compliance. At AI Tech Inspire, we see this as a practical reminder that deletion is a multi-system choreography: identity, session, storage, caches, and job queues all have to agree on the outcome.

For AI apps that process user content—videos, images, prompts, and embeddings—the stakes are higher. If a user expects deletion after a retention window, but a mobile session continues to function, users will understandably wonder: what exactly was deleted, and when?

What could be happening under the hood

  • Soft delete vs. hard delete: Many systems mark an account as disabled (soft delete) and then schedule data purges later. If web and mobile check different signals, one could block while the other lets a valid session slip through.
  • Session/token mismatch: Mobile refresh tokens with long TTLs not being invalidated on delete is a common pitfall. If the refresh token remains valid, the app can keep obtaining access tokens.
  • Conditional gating: The web might gate access on an account_status flag; the mobile app might only gate certain endpoints. If generation endpoints aren’t double-checking status server-side, they might still allow content creation.
  • Regional or environment drift: Web and mobile could be hitting different API gateways or environments inadvertently, especially during rollouts.
  • Eventual consistency lag or failed jobs: Background deletion jobs could fail quietly, leaving the system in a half-deleted state.

Key takeaway: if one client says “deleted” and another still works, don’t assume a UI bug. Verify token revocation and server-side enforcement at every endpoint.

Sora, generative video, and data footprint realities

Sora sits in the emerging class of high-compute, content-generating systems where assets (videos, frames, prompts, metadata) fan out across services. Even if the core identity record is flagged as deleted, lingering artifacts can persist in object stores, caches, or CDN layers. Developers working with similar stacks—think Hugging Face model hubs, or custom inference pipelines—should consider where user-linked content and logs live, and how to guarantee traces are gone when promised.

Typical touchpoints to audit in a video-generation pipeline:

  • Identity and auth: users table, OAuth providers, refresh token stores.
  • Generation services: job queues, workers, and model endpoints that may not read account_status on every request.
  • Storage: object stores (e.g., S3), backups, CDN caches, logs, analytics pipelines, and feature stores containing derivations.
  • Telemetry: crash logs, metrics, and traces that might hold user IDs or content hashes.

Checklist: harden your deletion flow

  • Define deletion levels: Disable (immediate access block), Quarantine (scheduled purge), Hard Delete (irreversible). Communicate which applies and when.
  • Atomic revocation: On delete, invalidate all sessions and refresh tokens. Consider a revoked_token set and short-lived access tokens (exp in minutes).
  • Server-side enforcement: Every protected endpoint checks account_status. Avoid relying solely on client gating.
  • Idempotent background jobs: Use a queue (e.g., Kafka or a reliable scheduler) to purge data; retries must not silently fail.
  • Multi-region consistency: Ensure writes propagate across regions before confirming deletion; add verification tasks.
  • Cache hygiene: Purge CDN and app caches; guard against stale authorization.
  • Proof of deletion: Log a verifiable audit trail and provide a user-accessible receipt.
  • Backup strategy: Document how backups age out or are encrypted with per-user keys that can be destroyed.

Developers can test their own flows by simulating deletion and observing whether endpoints still allow actions. A simple pattern is to force server-side checks like:

if (user.status !== 'active') return 403;

And, for tokens:

if (token.revoked || token.expired) return 401;

Why policy language isn’t enough

Stated retention windows (like the reported ~30 days) set expectations but don’t enforce themselves. If the system allows a mobile app to continue generating content after a delete event, users will assume the data wasn’t actually removed—or at least that the account is still operational in ways that matter. That perception gap can erode trust faster than any fine print can repair.

For teams operating under GDPR/CCPA-like regimes, consider mapping your Settings → Privacy → Delete Account UI to a concrete sequence of actions and SLAs. Even a brief in-product note clarifying the difference between access disablement and data purge can prevent confusion.

Comparisons and patterns seen across AI platforms

AI platforms differ widely in how they handle account deletion. Some developer-focused services lean on soft deletes so organizations can recover workspaces. Consumer-focused apps tend to push for faster hard deletes to align with user expectations. When models or datasets are involved, the thorniest question is what happens to derivative data—embeddings, cached generations, or fine-tuned model weights. Even if your product doesn’t finetune (e.g., pure GPT API usage) or relies on local inference like Stable Diffusion, you still have logs and metrics to consider.

In short: the more distributed your pipeline, the more places deletion has to reach. If you can’t produce a systems diagram that traces the path from identity deletion to cache invalidation, that’s a signal to invest in one.

If you’re investigating a similar issue

  • Reproduce systematically: Try new devices, reinstall, revoke from server, and confirm token invalidation. Capture timestamps.
  • Call the specific endpoints: Inspect which requests succeed post-deletion. Are generation or asset endpoints still 2xx?
  • Check headers and scopes: Access tokens might include scopes that bypass checks if not validated server-side.
  • Look for environment drift: Compare base URLs and regions used by web vs mobile.

If you discover inconsistencies, report them with precise steps. Most teams move fast to patch these once reproducible details land.

So, did deletion fail here?

This is a single report—worth paying attention to, but not a definitive verdict on backend deletion. It could be a session revocation bug, a gating oversight on specific endpoints, or a region mismatch. It could also be an expected soft-delete phase that’s not communicated clearly to users. Still, being able to “generate videos on a deleted account” is the kind of symptom that warrants immediate triage.

For users: deletion should feel final. For teams: design as if stale tokens will exist, and make sure they can’t do anything.

Bottom line

At AI Tech Inspire, this report reads like a cautionary tale for modern AI stacks: your deletion story is only as strong as your weakest client or endpoint. Whether you’re shipping a Sora-like video tool or a model-serving backend, treat deletion as a full-system feature with clear SLAs, rigorous revocation, and auditable results. Users will forgive minor UX hiccups; what they won’t forgive is ambiguity around their data.

Recommended Resources

As an Amazon Associate, I earn from qualifying purchases.