# I Tried to Fix a Vulnerability. A $1,400,000 AI System Said No. Twenty Days Later, That Vulnerability Cost $4,200,000. > Source: > Published: 2026-06-06 00:44:28+00:00 This story was shared by a fellow developer on DEV who asked to remain anonymous. If you've got a story to tell — come find me. Your name won't appear anywhere. Based on real microservice security design patterns. About an engineer whose PR got blocked by an AI security system — he thought he was fixing a vulnerability. Turns out, someone had a vested interest in that vulnerability staying open. All-hands meeting. CTO James stood at the front, a number on the screen: **$1,400,000** "This is what we're spending on security this year." He pointed at the number. "The biggest piece — right here." He clicked the remote. VoidSentinel's architecture topology appeared on screen. "VoidSentinel — an AI security platform. Integrated into our CI/CD pipeline. Starting today, every PR involving internal service-to-service calls — it reviews them automatically." The CEO didn't show up today. James didn't mention it. He looked straight at Mark — VP of Security. Mark took the mic. "VoidSentinel has been running in our pre-production environment for three weeks. It's caught 47 high-risk patterns. Zero false positives." He paused. "**— Of course, some people might feel uncomfortable when their PR gets blocked. But this isn't personal. This is the security standard.** " He wasn't looking at me. But I knew who he was talking about. The story started three weeks earlier. We had a payment service and a user service that talked to each other internally. They shared an old API key — one key across thirty-plus services, unchanged for five years. It wasn't that nobody knew. It just never made it to the top of the backlog. On Day 1, I opened a PR: add independent service-to-service auth between the payment and user services. Not much code — a new token exchange module, three call sites modified. Five minutes later, VoidSentinel's automated comment hit: **"High-risk alert: Unauthorized internal access pattern change detected. This PR has been automatically rejected. Contact the security team."** I stared at that comment for a long time. **This isn't "high risk."** This is adding independent auth between two services. This is fixing a hole that's been open for five years. I replied under the PR: "This PR fixes a shared credential vulnerability between services. It is not introducing a new attack surface. Please escalate for manual review." The next day, the reply came: **"VoidSentinel's verdict is final. Please reference the system's suggested modifications to adjust your code."** The system's "suggested modification" was: don't change anything. I walked to Mark's office. "That PR — it's not an attack. It's a fix. The payment service and user service are still sharing a five-year-old API key. If any one service gets compromised, the other thirty are exposed." Mark didn't look up. "VoidSentinel's model analyzed your code and flagged it as high risk. I trust its judgment." **"Its model can't read intent. It just sees someone modifying service-to-service auth — which looks exactly like what an attacker would do."** Mark finally looked up. **"So what's your suggestion? Everyone can just modify internal auth whenever they want, because 'I had good intentions'?"** " — Add a manual review gate. High-risk PRs go through AI first, then human review if rejected." **"I am the human review. The system flagged high risk, and I agree. PR denied."** I went back to my desk. I tried a different approach: instead of modifying the auth layer, add a call allowlist at the gateway level. That wouldn't trigger VoidSentinel's "service auth change" detection pattern. Submitted the PR. VoidSentinel verdict: **High risk. Denied.** — It recognized I'd changed the approach. The model's coverage was deeper than I thought. But it still couldn't cover the real vulnerability. Day 3. I got the PIP notice. Subject: **"Assessment of Alignment with Company Security Protocols"** Mark's office. He slid the PIP notice across the desk. **"Two attempts to bypass VoidSentinel's security review. This isn't a technical issue — it's an attitude problem."** "I submitted fixes. Not bypasses." **"From the system's perspective, you modified internal auth paths. The system flagged high risk. You changed the approach and submitted again. That's a bypass."** I looked at the PIP notice. **"30-day improvement plan. Success criteria: zero compliance violations. Fail — you're out."** I signed it. Walking out of Mark's office, I ran into Jay from ops in the hallway. He lowered his voice: **"— You know Mark's a board appointment, right? The CEO's been trying to move him for almost a year. Watch your back. Also — VoidSentinel? He picked it. Sold the board on it for six months before they approved it. You tell him he picked wrong — he's not going to admit it."** I nodded. Back at my desk, I opened VoidSentinel's architecture documentation. For the next 24 days, I did three things. **One: went through the PIP motions during the day.** No more touching service-to-service auth in any PR. VoidSentinel stopped flagging my code. Mark sent PIP progress emails every Friday. I replied every Friday with "on track." **Two: built a proof of concept at night.** VoidSentinel's core blind spot — I confirmed it — wasn't that it was too sensitive. It was that it applied **the exact same detection rules to fixes and attacks**. The code that fixes a vulnerability and the code that exploits one — to VoidSentinel's model, they're indistinguishable. **That means: it can't tell who's fixing something and who's breaking something.** It only knows someone's modifying service-to-service auth. Doesn't matter who you are, or why you're doing it. **Three: set up a monitor.** It didn't block anything. It just logged. Logged every "high-risk" PR VoidSentinel intercepted. Logged the PR content. The submitter. The resolution. I piped it to a server I controlled. Auth call logs from 138 service nodes, synced in real time. Mark didn't know. Jay didn't know. **Nobody knew.** Day 10. Mark sent a company-wide email: **"VoidSentinel has been live for two weeks. 217 high-risk PRs intercepted. Zero security incidents. This is the security standard we need."** I read that email. Then I opened my monitor. Out of 217 interceptions, 43 were security fixes that got falsely blocked. **And 3 of those fixes were for vulnerabilities that — if exploited — VoidSentinel couldn't detect at all.** Because those vulnerabilities weren't in north-south traffic. They were in the gaps between services. VoidSentinel can't see what it isn't deployed to look at. Day 22. Mark's office. "You're more than halfway through the PIP. How are things?" "On track." "Anything you want to talk about?" "No." He looked at me. **"Alex. Your technical skills are not in question. If you're willing to put something in writing — acknowledging VoidSentinel's security review process — the PIP can end early."** I stood up. **"VoidSentinel's security review process — 43 false positives. 3 of them blocked real fixes. That's the only thing I can put in writing."** I didn't wait for his response. Day 27. 2:47 AM. My phone lit up. Not a VoidSentinel alert — my own monitor. **"Anomaly detected: service-to-service auth call — credential KT-9f4 — flagged as 'high risk' by VoidSentinel, then automatically cleared three minutes later."** I sat up. Opened my laptop. At 1:12 AM, someone had initiated an auth call on the payment service's dev interface. Credential KT-9f4 — a service account belonging to an employee who left four months ago. VoidSentinel flagged it. Then automatically cleared it. Reason: **"Credential is valid. Call frequency normal. Classified as normal operation."** — The attacker used a legitimate credential. Normal frequency. Normal path. They just accessed a service they shouldn't. VoidSentinel recognized "someone's modifying service-to-service auth" — but after evaluating the call frequency and credential validity, its model decided this was a routine operation. **It did nothing.** I opened VoidSentinel's dashboard. Threat score: **0.02**. All green. Then I opened the Slack channel. **"Payment reconciliation is off by $4.2 million. Anyone looking?"** I took three screenshots: Then I opened the PR I'd submitted on Day 1. VoidSentinel's verdict: **High risk. Denied.** Fix content: independent auth between payment service and user service. — The exact same link that was exploited at 1:12 AM. I sent the three screenshots and that PR to CTO James. CC'd the CEO. **One line in the body:** **"Day 27. The thing I tried to fix on Day 1 — someone used it tonight. VoidSentinel flagged it for three minutes, then let it through. PIP has 3 days left. Your call."** CTO James. VP Mark. VP of Finance. VP of Legal. The CEO — everyone in the room. One person I didn't recognize sat in the corner. Someone called him a "board observer." James ran through the incident timeline first. When he said "the attack vector exploited an internal auth gap," the CEO raised a hand and stopped him. **"Alex. When did you submit your first PR?"** "Day 1." **"What was it for?"** "Independent auth between the payment and user services." **"What was VoidSentinel's verdict?"** "High risk. Denied." **"And then?"** I didn't answer. I opened the PR. I flipped to the first page — the code diff. A new token exchange module. Three call sites changed. **"This was a fix. VoidSentinel flagged it as high risk."** Then I flipped to the 1:12 AM attack log. **"This was an attack. VoidSentinel flagged it as high risk — then automatically cleared it. Reason: 'credential valid, frequency normal.' Same system. Same vulnerability. Same detection model. One blocked. One let through."** I closed the laptop. **"— Because VoidSentinel can't tell the difference between a fix and an attack. It only knows someone's modifying things. Whether that person is patching or exploiting — it doesn't know. It can't."** The room went quiet for a few seconds. The CEO didn't look at Mark. He looked at me. **"When were you put on PIP?"** "Day 3." **"What was the reason?"** "Two attempts to bypass VoidSentinel's security review." The CEO didn't say anything. He turned to Mark and asked quietly: **"He submitted a fix. You gave him a PIP. Is that right?"** James's eyebrow twitched. **"Mark. The report you gave me said 'two attempts to bypass security review.' You didn't mention he was submitting a fix."** Mark opened his mouth. "His submission method — " **"He proposed independent auth. You said no. He tried a gateway-level approach. You said no. The vulnerability he reported — someone exploited it tonight. Your system — flagged it for three minutes, then let it through."** The CEO's voice was flat. Flat enough that the silence after it felt heavier than any shout. Mark couldn't find words. The CEO stood up. **"Alex. My office."** I stood up. In my peripheral vision — Mark stayed seated. He didn't follow. The CEO walked fast down the hall. I followed. He didn't turn around. **"PIP rescinded. Effective immediately."** "Okay." **"Your fix gets deployed today."** " — VoidSentinel will block it." **"VoidSentinel gets reconfigured this afternoon. Your PR gets re-reviewed after the config update."** "Okay." He stopped. **"That monitor you built. How long has it been running?"** "Day 3." **"The day you got the PIP?"** "The day I got the PIP." He looked at me. Maybe five seconds. **"You know what it means — being on PIP and still building something that caught an attack before a $1.4M system did?"** " — It means those 27 days on PIP weren't wasted." He smiled. Not a "good job" smile. A different kind. **" — You know how Mark got that seat?"** I paused. "Board appointment, I heard." The CEO nodded. **"I waited eleven months for a reason."** He didn't finish the sentence. He didn't need to. I went back to my desk. Mark's desk was empty. HR had completed everything by 3 PM. I never replied to Mark's last PIP progress email. The last one sat at Day 27. Subject line: **"On track."** *Later, I reopened that Day 1 PR. VoidSentinel ran it again — this time it passed, with a note: "Low risk. Recommended to merge."* *I didn't feel good about it.* *I just remembered what Jay said to me in the hallway that day.* *— "The CEO's been trying to move him for almost a year. Watch your back."* *The reason he was waiting for was never about me.* *It was about someone finally handing him a board he didn't have to wait on anymore.* **Folks, when you submit a fix that gets blocked —** **are you fixing a bug, or finishing someone else's chess move?** 👇 *If you enjoyed this story:* • [My Company Bought a $660K AI Platform. I Was Replaced. On Friday at 2:58 AM, It Fixed Everything...](https://dev.to/xulingfeng/my-company-bought-a-660k-ai-platform-i-was-replaced-on-friday-at-258-am-it-fixed-everything-3kc4) • [Our VP's AI Wrote 3,000 Tests. Production Cost $700K. I Deleted Every Single One.](https://dev.to/xulingfeng/our-vps-ai-wrote-3000-tests-production-cost-700k-i-deleted-every-single-one-5536) • [The AI Test Report Said 97.3% Coverage. The Client's Lead Engineer Asked One Question. The Room Went Silent.](https://dev.to/xulingfeng/the-ai-test-report-said-973-coverage-the-clients-lead-engineer-asked-one-question-the-room-1cpi) • [I Built Open-Source AI. Our New CTO Spent $8M on His Old Company's Product and Fired My Team. Two Weeks Later, the CEO Called.](https://dev.to/xulingfeng/i-built-open-source-ai-our-new-cto-spent-8m-on-his-old-companys-product-and-fired-my-team-two-3jp8) • [My Company Spent $500K on an AI Platform. I Proposed an Open-Source Alternative and Got Fired. 6 Months Later, the Demo Crashed at 4 AM.](https://dev.to/xulingfeng/my-company-spent-500k-on-an-ai-platform-i-proposed-an-open-source-alternative-and-got-fired-6-4dlc) *To the person fixing vulnerabilities at 3 AM — this one's for you. Buy me a coffee ☕*