AI just killed security through obscurity on IBM i in 2026

Carol Woodbury, one of the most respected security researchers in the IBM i world, needed one search to find a working SQL command that lists every library on a system. She typed it into Gemini. It came back in seconds. That’s IBM i security in the AI era, 2026 edition: the thing that killed security through obscurity, and most shops haven’t updated their defenses to match.

Obscurity was never a real control, and now it’s gone

IBM i shops have leaned on a quiet assumption for decades: nobody outside the IBM i world understands this system well enough to attack it. Green screens, unusual terminology, and a small talent pool made the platform feel invisible to outsiders. That was never a documented security control, it was an accident of low attacker interest.

AI removed the accident. Any large language model, Gemini, Copilot, Claude, can now explain IBM i authority structures, generate the SQL to enumerate libraries and objects, and summarize the platform’s known CVEs, all from a plain-language question. Justin Loeber of Kisco Systems put it plainly during a March 2026 security webinar with Woodbury: AI has completely destroyed whatever protection security through obscurity offered. The knowledge gap that used to separate IBM i shops from casual attackers closed to almost nothing.

This doesn’t mean IBM i is suddenly less secure than it was last year. It means the protection you were quietly counting on stopped working, and the protections that were always the real ones, authority discipline, exit point control, audit logging, are now the whole plan instead of a backup plan.

What Fortra’s 2026 data says shops actually have in place

Fortra’s 23rd annual State of IBM i Security report scanned 163 real IBM i partitions in 2026, and the results are a mix of genuine progress and the same problems showing up year after year.

The good news first. 87% of scanned systems run at QSECURITY level 40, largely because IBM ships that as the default starting with IBM i 7.5. Use of the dangerous *ALLOBJ special authority dropped to 8% of users, continuing a multi-year decline. The security audit journal is turned on in 96% of systems, the highest it’s been, and it costs nothing extra since it’s built into the OS.

The bad news is specific and fixable. 10% of systems still have default passwords in active use, up from 8% in 2025, and one scanned system had more than 11,000 user profiles carrying default passwords, 80% of them still enabled. The average system now has 889 users holding *JOBCTL authority and 649 holding *SAVSYS, both up significantly year over year. Fortra’s Amy Williams didn’t soften it: “*JOBCTL and *SAVSYS are winning the race, which is just terrible.” *JOBCTL alone can end jobs and subsystems across the entire machine, and it shouldn’t be handed out by default.

Exit programs, the software that governs access through network protocols like FTP, ODBC, and TCP/IP, are now in place on 73% of systems, up sharply from 35% in 2024. But only 31% have full coverage across the 27 most common exit points, and Fortra found that even where exit programs exist, many are misconfigured and not actually restricting access the way admins assume.

The exact hijack path AI can now hand anyone

During the same March webinar, Woodbury demonstrated an attack path that starts from a completely unprivileged user profile. Using Run SQL Scripts in IBM i Access Client Solutions, a plain user account with no special authorities can query which libraries and user profiles are missing the PUBLIC *EXCLUDE setting. Finding one is common, not rare. From there, a few more SQL commands let that low-privilege user effectively take over a profile that does carry special authorities, gaining full command-line access to the system.

“Oh, looky here,” Woodbury said, describing what a scan like this typically turns up. “This is a user profile that has all special authorities but is not public *EXCLUDE. I wish this was a rare occurrence, but it is not.”

What used to gate this attack was knowledge: understanding IBM i’s authority model well enough to know what to search for. That gate is gone. Ask any current AI model how IBM i authority checking works and how PUBLIC *EXCLUDE gaps get exploited, and you’ll get a usable answer. The fix hasn’t changed, though: audit every profile for PUBLIC *EXCLUDE, minimize special authorities to the people who need them and only when they need them, and use temporary elevation instead of standing access for admin work.

AI agents and MCP need the same discipline as human users

IBM i shops are starting to connect agentic AI to their systems, often through Model Context Protocol, the standard Anthropic introduced in late 2024 for letting AI agents talk to data sources and to each other. MCP shipped without built-in security features. OAuth 2.1 authentication and stronger authorization models arrived later in 2025, but the protocol is still young, and IBM’s own MCP work for IBM i is new enough that security guidance hasn’t caught up to adoption.

IBM is positioning its Mapepire database client as the connection point for AI and MCP traffic into IBM i. Under the surface, Mapepire runs on ODBC, so every ODBC lockdown practice your shop already has, exit programs, connection restrictions, monitoring, applies directly to it. Loeber’s warning is worth repeating in plain terms: connections through Mapepire and ODBC bypass menu security and other application-layer protections entirely, and that’s true whether the connection comes from a person or an agent.

The practical rule is simple, and it’s the same rule covered in more depth in our guide to starting IBM i modernization with AI: treat every AI agent exactly like a user profile: give it the minimum authority required for its task, restrict which other agents or systems it can talk to, and watch its activity through the same exit points and audit journal entries you’d use to track a person. Loeber’s team has been doing this for a client already, using SQL server exit points and audit journal SK entries (socket and IP traffic) to see when an agent reaches out to an external API. An agent that’s allowed to do anything, with no one reviewing what it actually does, is a bigger risk than the attacker AI supposedly protects you from.

The ransomware path most shops still leave open

Ransomware doesn’t need to compromise IBM i directly to hurt it. A single infected Windows PC on the same network can reach IBM i’s Integrated File System through mapped network drives (QNTC), shared folders (NetServer), or active FTP connections, and encrypt whatever it can reach there. IBM’s own support documentation confirms this is one of the most common real-world paths ransomware takes onto the platform.

The highest-leverage fix costs nothing: set IFS file shares to read-only wherever write access isn’t strictly required. Pair that with multi-factor authentication on the accounts and protocols that can reach the IFS, and you close most of the practical path malware actually uses to reach IBM i data.

The 2026 lock-down checklist, in order

Work through these in priority order. Most of them are free and built into the OS.

1. Confirm the security audit journal is on and being reviewed, not just switched on and forgotten. This is your forensic record if anything else on this list fails.
2. Audit every user profile for PUBLIC *EXCLUDE gaps, especially any profile carrying special authorities. This is the exact path Woodbury demonstrated turning an AI search into full system access.
3. Cut *JOBCTL and *SAVSYS authority down to the people who need it for their actual job, and consider temporary elevation instead of standing access.
4. Eliminate default passwords across all profiles, and enforce a minimum length that actually meets a real standard, 12 characters minimum, not 6 or 8.
5. Deploy exit programs across all your active network protocols, not just some, and verify they’re actually restricting access, not just logging it.
6. Set IFS file shares to read-only wherever possible, and require MFA on any account or protocol that can reach the IFS.
7. Treat every AI agent connecting to IBM i as a user profile: minimum authority, monitored access, no unrestricted agent-to-agent connections.

Bottom line

Security through obscurity was always a myth for IBM i, it just hadn’t been tested yet. AI tested it in 2026 and it failed immediately. None of the real fixes are new or exotic. They’re the same authority discipline, exit point control, and audit logging that security professionals have recommended for two decades, and Fortra’s own data shows most shops have only partially adopted them. This gap matters even more against the backdrop of the IBM i retirement wave: fewer senior admins are around to catch these misconfigurations by instinct, so the checklist above has to replace tribal knowledge that’s walking out the door. The same discipline gap shows up in how most shops handle PTF management: no cadence until an audit or an incident forces one. The shops that close these gaps now are the ones that stop finding out about breaches after the fact. For a structured way to bring AI into an IBM i shop without introducing this kind of exposure, the IBM i Field Guide covers the workflow and authority patterns that keep AI tools inside safe boundaries.

Frequently asked questions

Is IBM i still secure if it’s not connected to the internet?

Most IBM i systems today are connected, through FTP, ODBC, web services, or a Windows box on the same network with IFS access. Isolation was the actual protection obscurity gave you, and few shops still have it. If your system talks to anything else on the network, obscurity was already gone before AI entered the picture.

Can AI tools like Copilot or Gemini really help someone attack an IBM i system?

Yes. Security researcher Carol Woodbury demonstrated getting a working SQL query to list every library on a system from a single Gemini search. The same tools can summarize known IBM i CVEs, explain authority structures, and outline attack paths that used to require years of specialized knowledge.

What’s the single highest-impact fix for IBM i security in 2026?

Turn on the security audit journal if it isn’t already (96% of shops have it on, so check that you’re in the 4% that doesn’t), and audit every user profile that isn’t set to PUBLIC *EXCLUDE. Both are free, built into the OS, and close the exact hijack path documented in Fortra’s 2026 research.

Do AI agents connecting to IBM i need special security treatment?

Treat every AI agent as its own user profile with the minimum authority it needs, nothing more. Monitor its activity through exit points and the audit journal the same way you’d monitor a contractor’s account, because an agent with excess authority is exactly as dangerous as a person with excess authority.