Artificial intelligence is reshaping the security landscape, and IBM i environments are no exception. As AI-driven technologies become integral to enterprise operations, they create the opportunity for faster detection, smarter prioritization, and better visibility, but they also introduce new risk through new workflows, new automation, and a lowered barrier to making impactful changes. In other words: AI can be a security enabler and a security attack amplifier.
IBM i administrators and developers, security leaders, auditors, and IT stakeholders need to pay attention because AI is data hungry and your most valuable data is on your IBM i.
The State of IBM i Security: AI Raises the Stakes on Long-Standing Gaps
Many IBM i environments still have correctable exposures in foundational controls, not because teams don’t care, but because the platform has a long-standing, misguided reputation as being inherently secure. The stability and longevity of these systems has allowed lax controls to perpetuate.
As teams adopt AI assistants and agentic workflows, weak controls become easier to discover, easier to exploit, and harder to explain to auditors after the fact.
Foundations that matter even more in an AI era: understand who can access what data (and through which entry point – there are many!), enable auditing across all access points, and translate IBM i security events so non-IBM i security teams can act on them.
Establish a Baseline (Before You Add AI to the Mix)
If you’re not proactively assessing your current security posture, it’s easy to confuse “we’ve never had an incident” with “we’re secure.” In practice, teams get traction by combining a snapshot assessment with repeatable operational monitoring:
Run a security configuration scan to generate a baseline report and highlight common IBM i exposures.
Automate monitoring so inappropriate configurations don’t quietly accumulate between audits.
Perform a periodic deep-dive risk assessment that maps current system settings to best practices and produces auditor-friendly findings and remediation guidance.
Modernize authentication (for example, SSO and MFA) to reduce password sprawl and improve the consistency of access control.
Validate with penetration testing when required by governance or auditors and treat remediation as an ongoing program - not as a one-time project.
AI as a Security Enabler: Faster Detection, Better Prioritization, Less Noise
Used well, AI can help security teams move from “more alerts” to “more signal.” Modern AI-powered security capabilities can spot abnormal access patterns, summarize incidents for analysts, and accelerate triage, which is going to improve speed and consistency without removing humans from the decision loop.
Faster threat detection and triage: AI can help identify anomalies and produce useful summaries so analysts spend less time on “what happened?” and more time on containment and recovery.
Predictive risk analysis: by correlating signals across tools and time, AI can help teams prioritize which exposures are most likely to turn into incidents next.
Operational automation: use AI to accelerate repeatable work (classification, routing, evidence collection), while keeping change approval and high-risk actions governed.
Compliance readiness: AI can help turn raw events into auditor-consumable narratives—especially when IBM i teams must explain platform-specific events to broader security and GRC stakeholders.
AI as a New Attack Vector: Same Risks, Less IBM i Skills Required
Here’s the uncomfortable reality: “free” and company-endorsed AI chatbots can make it dramatically easier for inexperienced users to generate commands, scripts, and step-by-step instructions that change configurations or access data. This doesn’t automatically create a breach, but it does increase the odds of well-intentioned changes being made without understanding IBM i-specific security implications (for example, opening an access path to “get something working,” then forgetting to roll it back).
Lowered barrier to change: AI can quickly generate “the command to run” or “the setting to flip,” even when the user doesn’t fully understand downstream impact.
Misplaced trust: generic AI answers may sound confident while missing IBM i nuance (authorities, exit points, adoption, audit journaling, etc.).
Exception creep: when AI suggests workarounds, teams may normalize one-off exceptions that quietly become permanent exposures.
Amplified insider risk: if a user already has excessive authority, AI can make it easier to misuse, or even abuse, that authority only now they can do it faster and with fewer mistakes.
Governance and Guardrails: Make AI Use Safe by Design
Validate AI outputs against IBM i best practices: treat AI as a starting point, not an authority. Require peer review for any change that touches authorities, exit points, auditing, or network services.
Constrain who can change what: least privilege is no longer “nice to have” (never should have been!) It should be your primary control against AI-accelerated mistakes.
Update policy for AI-era workflows: define where AI tools may be used (and not used), what data may be pasted into them, and how AI-generated scripts/commands are approved and logged.
Train for AI literacy: make sure admins, developers, and auditors recognize the difference between plausible-sounding advice and platform-specific guidance.
Prepare for agentic integrations: IBM i is increasingly being connected into AI workflows via MCP servers and related tooling which amplifies the need for authentication, authorization, observability, and auditability.
An IBM i “AI-Ready Security” Checklist (Start Here)
Lock down powerful authorities: inventory profiles with special authorities (especially *ALLOBJ and *SECADM), reduce counts, and document break-glass access.
Review system values: align to best practices with your risk tolerance and compliance needs in mind and continuously monitor for drift.
Harden network access paths: verify exit point coverage and rule sets for the services you actually use and adopt a “deny-by-default” approach. Implementing Fortra’s Powertech Exit Point Manager is a powerful solution to help achieve this.
Turn on (and tune) auditing: ensure you can answer “who did what, when, from where and how” across interactive, batch, and network access.
Reduce *PUBLIC exposure: review public authority to libraries and critical objects, and adopt a zero-trust mindset.
Translate IBM i events for enterprise security: make logs and audit evidence consumable for SOC/GRC teams who don’t live on IBM i every day. This will require adding an Agent to the IBM i to handle those events, such as Powertech SIEM Agent for IBM i.
Govern AI usage: define what can be shared with chatbots, require review for AI-generated commands/scripts, and keep approvals auditable.
Plan for agents: if you’re exploring MCP/agentic integration, treat tool access like an API: authenticate strongly, authorize narrowly, observe continuously.
Run the Powertech Security Scan to See if Your IBM i Security is AI-Ready
If AI is on your roadmap, whether it’s AI-assisted operations, AI-driven security analytics, or agentic workflows that can query data and take actions, your IBM i security posture becomes an integral part of your AI readiness. The fastest way to get moving is to run the Powertech Security Scan: it’s a complimentary, non-intrusive assessment designed to highlight common IBM i security exposures, produce a baseline report you can save and share, and guide remediation without changing any of your system settings. Many organizations rerun the scan after fixes to confirm measurable improvement, and a Security Advisor can help interpret findings and next steps.
