# Service Account API keys Disappearing **URL:** \ **Category:** Bugs\ **Created:** [March 2, 2026, 8:08pm UTC](https://community.openai.com/t/service-account-api-keys-disappearing/1375520 "2026-03-02T20:08:26Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![fabrizio.cucci](https://avatars.discourse-cdn.com/v4/letter/f/a587f6/32.png) [@fabrizio.cucci](https://community.openai.com/u/fabrizio.cucci)\ **Post date:** [March 2, 2026, 8:08pm UTC](https://community.openai.com/t/service-account-api-keys-disappearing/1375520/1 "2026-03-02T20:08:26Z")
Hi everyone, I’m running into a recurring issue where our OpenAI API keys keep disappearing. The key is an API key created for a service account. It is stored only as a secret in Google Cloud and used exclusively by backend functions that have access to that secret. The key is not exposed anywhere else and is never embedded in client applications. Despite this setup, the key periodically stops working because it appears to have been removed or invalidated. This is heavily impacting our production applications since services suddenly fail when the key disappears. Has anyone experienced something similar or knows what might be causing this? Any guidance on where to look or how to prevent this would be greatly appreciated. Thanks in advance. ---
**Author:** ![VeitB](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/veitb/32/712987_2.png) [@VeitB](https://community.openai.com/u/VeitB)\ **Post date:** [March 3, 2026, 10:20pm UTC](https://community.openai.com/t/service-account-api-keys-disappearing/1375520/2 "2026-03-03T22:20:47Z")
Hi and welcome back! The most straightforward explanation would be that someone with an admin key is revoking these keys. That said, we recently had a similar report where this possibility was ruled out. The discussion also includes several suggestions on where to check for unexpected key deletion. > [@Service account API keys silently disappearing — no audit log events, no leak notification](https://community.openai.com/t/service-account-api-keys-silently-disappearing-no-audit-log-events-no-leak-notification/1374936): > > I’ve experienced my service account API key being deleted without explanation twice now. Looking for anyone who has encountered the same issue or any insight from the community. Environment: Key type: Service account key Organization: Multi-member Plan: Non-enterprise (unable to contact support directly) What happens: The service account key completely disappears — not just from the UI, but the key stops working entirely (API requests return authentication errors). This has happened twice … ---
**Author:** ![bsph.ctl](https://avatars.discourse-cdn.com/v4/letter/b/aca169/32.png) [@bsph.ctl](https://community.openai.com/u/bsph.ctl)\ **Post date:** [March 4, 2026, 3:25pm UTC](https://community.openai.com/t/service-account-api-keys-disappearing/1375520/3 "2026-03-04T15:25:11Z")
This just happened to **all** of the API keys in our account. Both older and newer keys are gone. I’m the account owner/admin, and I assure you that I did not delete any API keys. The keys are not exposed publicly in any way, and reside encrypted on our servers. ---
**Author:** ![VeitB](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/veitb/32/712987_2.png) [@VeitB](https://community.openai.com/u/VeitB)\ **Post date:** [March 4, 2026, 3:29pm UTC](https://community.openai.com/t/service-account-api-keys-disappearing/1375520/4 "2026-03-04T15:29:22Z")
I have flagged this to team. In the meantime I am attempting to repro the issue. ---
**Author:** ![\_j](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/_j/32/766292_2.png) [@\_j](https://community.openai.com/u/_j)\ **Post date:** [March 4, 2026, 3:32pm UTC](https://community.openai.com/t/service-account-api-keys-disappearing/1375520/5 "2026-03-04T15:32:56Z")
Here’s the test: Make three keys. Never use or even copy out two of them. If the one key in use is disappearing and the others remain - you are leaking it, which might be some key auto-reporting done by one of the larger repos or hosts with agreements with OpenAI. ---
**Author:** ![fabrizio.cucci](https://avatars.discourse-cdn.com/v4/letter/f/a587f6/32.png) [@fabrizio.cucci](https://community.openai.com/u/fabrizio.cucci)\ **Post date:** [March 4, 2026, 4:20pm UTC](https://community.openai.com/t/service-account-api-keys-disappearing/1375520/6 "2026-03-04T16:20:29Z")
Hi all, thanks for the responses so far. Just to clarify a few important points: - I am the **only admin/owner** of the account. - No one else has access to delete or rotate keys. - The keys are **not exposed publicly** in any way. - They are stored exclusively as secrets in Google Cloud using `firebase functions:secrets:set ` and are only accessed by backend Cloud Functions. - They are never embedded in client apps, repos, CI logs or anywhere else. I’ve now tested this with both **service account keys** and **non-service account keys** , the same issue occurs. More generally, even if a leak were detected, automatically deleting a production API key without explicit confirmation from the account owner is extremely disruptive. At the very least there should be a toggle or policy setting that lets the account owner decide whether to: - auto-revoke immediately - notify only - or require manual confirmation In our case, keys are disappearing without warning, which is heavily impacting production systems. Is there any way to escalate this to support for a specific account investigation? We are on a non-enterprise plan, so we don’t have direct support access but this is a production-impacting issue and we would really love to have some clarity on what is happening. Appreciate any help. ---
**Author:** ![\_j](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/_j/32/766292_2.png) [@\_j](https://community.openai.com/u/_j)\ **Post date:** [March 4, 2026, 4:49pm UTC](https://community.openai.com/t/service-account-api-keys-disappearing/1375520/7 "2026-03-04T16:49:16Z")
Audit logging. Once turned on, it is permanently on. Then: ![image](https://us1.discourse-cdn.com/openai1/original/4X/f/5/6/f5637cabbefc1c4a3a244af6e9d58af643b016fd.png) The only thing the events don’t specifically detail is that api\_key.deleted would include admin keys - but you can record the value and delete one yourself, along with deleting a project’s API key, and see that you then have logging. The mystery will then only be in the future if it is “you” who is doing the logged deleting - then you have to go on full lockdown (intrusion without other detected abuse or billings would be a strange thing). ---
**Author:** ![VeitB](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/veitb/32/712987_2.png) [@VeitB](https://community.openai.com/u/VeitB)\ **Post date:** [March 4, 2026, 9:52pm UTC](https://community.openai.com/t/service-account-api-keys-disappearing/1375520/8 "2026-03-04T21:52:47Z")
The audit logs would be the first place to check. In the other topic I linked above, the OP mentioned they could not find any audit log entries related to the missing key. Today, OpenAI published an update on the status page stating that the audit logs were affected by a bug and that the missing data is currently being backfilled. That may help clarify what happened. > **[Issues with API Platform Audit Logs - OpenAI Status](https://status.openai.com/incidents/01KJXA4N2X4W8KHZFSSFH0V0Q7/write-up)** > > We have observed issues with API Platform audit logs. ---
**Author:** ![\_j](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/_j/32/766292_2.png) [@\_j](https://community.openai.com/u/_j)\ **Post date:** [March 5, 2026, 3:02am UTC](https://community.openai.com/t/service-account-api-keys-disappearing/1375520/9 "2026-03-05T03:02:54Z")
That’s a nice format of report. It doesn’t let us fully understand: - are admin keys or service keys also logged? - how these keys are actually going missing. Answring requires flip of a permanent org switch to find out the comprehensiveness of audit logging, though. Thus I suggest ensuring discoverability first, or perhaps others can report the result and verbosity of deleting a temporarily-created key and retrieving logs. Audit logging may let one discover their nefarious multiple personality sleepwalking disorder that likes to delete keys? Or that you are completely blameless, and this indicates impactful silent corruption of data by OpenAI. The report did inspire me to apply and demonstrate the application of AI to my own incident report writing… * * * > **Hypothetical: Data Corruption Affecting a Subset of Multidomain API Keys** > > ## Root Cause > > In March 2026, we experienced a data integrity incident affecting a small subset of customers whose organizations spanned multiple domains and sites in our multi-region Kubernetes deployment. > > Our PostgreSQL cluster was deployed across multiple sites with storage layers that relied on distributed block devices. Under a specific failure mode involving cross-site replication timing and index page writes, certain index entries were written with invalid 64-bit file offsets. These offsets pointed beyond the valid 32 TB addressable file space configured for the underlying storage. > > From PostgreSQL’s perspective, these writes appeared successful at the system call level. However, the invalid offsets caused sparse file regions to be created in the data files. The underlying filesystem accepted the writes by creating holes (sparse segments) rather than rejecting the operation. As a result: > > - Some index pages referenced heap data that was never durably written. > - Certain rows became logically unreachable through normal index scans. > - In rare cases, subsequent VACUUM and autovacuum processes treated those rows as non-existent or removable. > - Affected records appeared to “delete themselves” over time, particularly API keys belonging to multidomain organizational units. > > The corruption was limited in scope because it required a specific alignment of cross-site write timing, index updates, and storage layer behavior. It did not affect the majority of tenants or single-domain organizations. > > Binary-level inspection of affected relation files confirmed the presence of sparse regions and index entries containing non-canonical block references. Some data pages contained partial or invalid content that could not be reliably reconstructed. For security reasons, if data appeared non-functional, unreachable, or semantically ambiguous, we chose not to restore it. > > At the time of the incident, we lacked comprehensive guardrails to detect invalid block references at the storage boundary, and our monitoring did not include invariant checks for sparse file growth or out-of-range page offsets. > > * * * > > ## Incident Response > > In early March 2026, customer reports indicated that API keys associated with certain organizational structures were disappearing without corresponding audit events. > > Engineers began investigating application-layer logs and database-level audit trails. Initial hypotheses focused on application logic or key lifecycle automation. However, deeper inspection revealed inconsistencies between expected row counts and index traversal results. > > We: > > - Performed integrity checks using PostgreSQL tools (`amcheck`, catalog validation). > - Identified index corruption localized to specific relations tied to multidomain organization units. > - Examined relation files at the filesystem level and discovered sparse file regions. > - Correlated these regions with invalid block references embedded in index pages. > > Once the corruption vector was understood, we: > > - Isolated affected clusters. > - Disabled cross-site write paths implicated in the issue. > - Rebuilt corrupted indexes. > - Restored valid data from physical backups and logical replication streams where possible. > > Where rows were provably intact in heap pages and could be reconciled against consistent snapshots, we restored them. Where page contents were partially written, referenced invalid offsets, or conflicted with security guarantees, we did not attempt reconstruction. > > * * * > > ## Data Recovery Status > > The incident affected a small subclass of API organization units operating in multidomain configurations. > > Impacted objects included: > > - API keys > - Associated organization-unit metadata > - Select index structures supporting key lookups > > Recovered: > > - API keys and metadata fully present in validated backups > - Keys reconstructable from logical replication logs > - Organization records with intact heap pages > > Not recoverable: > > - Rows whose heap pages were partially written into sparse regions > - Records only referenced via corrupted index entries with invalid block offsets > - Data segments that appeared unreachable and were subsequently vacuumed > > For security and compliance reasons, ambiguous or partially corrupted API keys were not restored. Affected customers were required to regenerate new keys. > > * * * > > ## Our Response and What We’ve Changed > > We implemented architectural and operational changes to prevent recurrence: > > 1. **Storage Safeguards** > > 2. **Database Hardening** > > 3. **Replication and Topology Changes** > > 4. **Monitoring Improvements** > > 5. **Operational Resilience** > > We are also conducting a broader review of how distributed storage semantics interact with PostgreSQL’s assumptions about durable, bounded block devices. > > * * * > > ## Organizational Context > > During this period, we experienced significant personnel turnover unrelated to the technical failure. This resulted in a loss of institutional knowledge around certain infrastructure decisions, including historical storage-layer tradeoffs. > > While this did not directly cause the corruption, it increased time-to-diagnosis and slowed early-stage hypothesis validation. We recognize that operational continuity is a reliability concern, and we are investing in documentation, peer review, and cross-training to mitigate similar risks in the future. > > We apologize for the instability and disruption this incident caused. > > * * * > > ## What This Means for You > > If you were affected: > > - Some API keys may have become invalid without an explicit deletion event. > - Regeneration of those keys was required. > - No evidence suggests unauthorized third-party access as a result of this issue. > - Corruption was structural, not adversarial. > > If you maintain internal logs of API key provisioning or rotation, those records may help reconcile activity during the affected period. > > * * * > > We take data durability and integrity seriously. This incident exposed a rare but serious interaction between distributed storage behavior and database indexing assumptions. We have reinforced both technical controls and operational practices to ensure this class of failure is prevented and rapidly detected in the future. > > Thank you for your patience and continued trust. ---
**Author:** ![OpenAI\_Support](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/openai_support/32/561845_2.png) [@OpenAI\_Support](https://community.openai.com/u/OpenAI_Support)\ **Post date:** [April 22, 2026, 12:23pm UTC](https://community.openai.com/t/service-account-api-keys-disappearing/1375520/10 "2026-04-22T12:23:27Z")
Hey everyone, can someone please confirm if audit logs helped and if this issue is still happening? more than happy to take a look. ---
**Author:** ![VeitB](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/veitb/32/712987_2.png) [@VeitB](https://community.openai.com/u/VeitB)\ **Post date:** [April 22, 2026, 12:55pm UTC](https://community.openai.com/t/service-account-api-keys-disappearing/1375520/11 "2026-04-22T12:55:15Z")
Hi! From my perspective, I created a few service accounts along with keys for those accounts, and nothing unexpected happened over several weeks. I can’t confirm whether the same applies to the OP, though. Hope this helps! ---
**Author:** ![Prashant\_Pardesi](https://avatars.discourse-cdn.com/v4/letter/p/f9ae1b/32.png) [@Prashant\_Pardesi](https://community.openai.com/u/Prashant_Pardesi)\ **Post date:** [April 26, 2026, 10:53am UTC](https://community.openai.com/t/service-account-api-keys-disappearing/1375520/12 "2026-04-26T10:53:35Z")
Closed on April 26, 2026, 10:53am UTC