For decades, mainframe security has relied on a fundamental principle: before a user or application is allowed to access a protected resource, the system must determine whether the appropriate authority exists.
On z/OS, the System Authorization Facility (SAF) provides a common interface through which resource managers can request security services. RACF, ACF2 and Top Secret are external security managers (ESM) that can enforce the relevant security policies.
This is something mainframe security professionals understand very well.
But the increasing use of Artificial Intelligence, particularly AI agents capable of interacting with external tools and applications, introduces an interesting security challenge. What happens when an AI agent uses legitimate authority to perform an operation that nobody actually intended it to perform?
In this article, I want to explore why this matters, how it could affect mainframe environments and why some of the security principles we have been applying for decades are becoming even more important.
Understanding the Problem
One of the security risks associated with Large Language Models (LLMs) is known as prompt injection.
According to the OWASP Top 10 for LLM Applications, prompt injection occurs when crafted input influences an LLM into behaving in ways that were not intended by the application.
An important variation is indirect prompt injection. Instead of issuing malicious instructions directly to an AI application, an attacker places those instructions inside information that the application is expected to process. This could be a document, a web page, an email, a log entry or another source of external information.
The problem arises when the AI interprets that information as instructions rather than treating it as data.
For an AI application that only generates text, the consequences may be limited to an incorrect or manipulated response. However, when an AI agent can invoke tools, execute operations or interact with other systems, the consequences can be considerably more serious. OWASP identifies this related problem as Excessive Agency.
In simple terms, an AI application may be given more functionality, permissions or autonomy than it actually needs. Now consider how this could affect a mainframe environment.
A Practical Example
Imagine an organisation develops an AI assistant to help its operations team investigate production problems. The assistant can retrieve selected system messages, examine job output, search technical documentation and access operational information through authorised interfaces. These are perfectly reasonable capabilities for an operational assistant.
Now imagine that an attacker manages to insert malicious instructions into information the assistant will subsequently process. For example, an application log might contain text instructing the assistant to retrieve sensitive configuration information and transmit it to an external destination. The attacker wants the assistant to interpret those instructions as part of its operational task.
If the application fails to distinguish untrusted content from legitimate instructions, the agent might attempt to invoke an available tool to perform the requested operation. Whether that attempt succeeds depends on several factors, including the tools available to the agent, their permissions, the application’s validation controls and the security mechanisms protecting the underlying resources.
It is important to understand that this is a hypothetical example of a known class of AI security risk. It is not a claim that any particular IBM Z AI product is vulnerable.
Nevertheless, it illustrates an important point. An attacker may not need to compromise a privileged identity if they can manipulate an application that already has access to privileged functionality.
But Wouldn’t RACF Prevent This?
Not necessarily. And this is where we need to understand the difference between authorisation and intent.
Suppose the AI agent invokes an application tool that attempts to read a protected z/OS dataset. Depending on the architecture, the request may be processed using the identity of the original user, an application service identity or another appropriately established security context.
Where the relevant resource manager performs a SAF authorisation check, the request is evaluated according to the applicable security configuration.
If RACF is the external security manager, RACF processes the relevant request according to the resource class, security attributes, profiles and other applicable controls. If access is denied, the operation should not proceed through that protected interface.
However, if the effective identity is authorised, the request may be permitted. RACF has not necessarily failed. It has performed the access-control function for which it was designed.
What RACF cannot determine is whether the AI agent decided to make the request because of a legitimate instruction or because it was influenced by malicious information. That distinction is fundamental.
An operation can be properly authorised at the resource level while still being inappropriate in the context of the original request.
The Service Identity Problem
Let’s consider another situation. An organisation develops an AI application that interacts with z/OS through an API or middleware service. The service runs under a dedicated identity that has access to several operational functions. Perhaps it can retrieve dataset information, examine job output and submit certain jobs. This is not unusual. Service identities have been used for many years.
The problem arises when the permissions assigned to the service exceed what the AI application actually requires. For example, an assistant intended to investigate batch failures may only need to retrieve job status and output. If the same interface also permits arbitrary job submission, the assistant has access to functionality that is unnecessary for its intended purpose. An incorrect or manipulated AI response could then result in the application attempting an operation outside the intended workflow.
This is an example of excessive functionality or excessive permissions. The solution is not simply to tell the AI that it must never submit unauthorised jobs. The application should enforce those restrictions independently.
If the AI doesn’t need job-submission capability, don’t make that capability available to it. If it only needs to retrieve information, use interfaces and identities restricted to the required read operations. And if an operation requires additional approval, that approval should be enforced outside the model’s own decision-making process.
What About Surrogate Authority?
There is another z/OS security mechanism worth considering: Surrogate authority. RACF supports authorised surrogate job submission through the SURROGAT general resource class.
For example, a user can be permitted to submit a batch job that executes under another user’s identity without needing that user’s password.
The relevant resource profile follows the naming convention:
execution-userid.SUBMIT
An appropriately authorised surrogate requires the necessary access to that profile, subject to the applicable RACF configuration and additional security requirements.
Once the job executes under the execution user’s identity, the job’s resource access checks are performed using that execution identity. This is a legitimate and useful security capability.
But consider what it means for an AI-connected application. Suppose the application invokes a job-submission tool that has been authorised to submit work on behalf of another identity. The AI may not directly possess the execution user’s dataset permissions. Nevertheless, the tool could initiate work that runs under that identity if the relevant surrogate and job-submission requirements are satisfied.
The distinction matters. When assessing an AI integration, we need to understand not only which identity invokes the tool, but also which identity ultimately executes the requested operation.
We also need to understand which controls authorise that transition. Otherwise, we risk underestimating the effective authority available through the application.
The Security Manager Doesn’t Understand Intent
This is perhaps the most important point. RACF doesn’t interpret natural-language instructions. It doesn’t determine whether an LLM has misunderstood a document. It doesn’t know whether an AI agent has been influenced by malicious content. And it doesn’t determine whether an operational recommendation is technically sensible. That isn’t a limitation specific to RACF. It reflects the difference between enforcing access-control policy and understanding the intent behind an application request.
An external security manager can enforce the access rules applicable to a protected resource. But the application remains responsible for ensuring that its requests are appropriate.
With AI agents, that responsibility becomes more complicated because the application may allow the model to select tools and generate parameters dynamically. This means organisations need controls at more than one level. The underlying resources must remain properly protected. The interfaces exposing those resources must enforce appropriate restrictions. And the AI application must not be able to convert untrusted content into unrestricted operational requests.
Not Every AI Tool Should Be an Administrative Tool
Consider three examples.
- An AI assistant investigating a JES2 problem may need to retrieve job status and selected spool output. That doesn’t mean it needs unrestricted job-submission capability.
- An AI assistant analysing a RACF access failure may need to retrieve diagnostic information about the relevant security profiles. That doesn’t mean it needs authority to modify access lists.
- And an AI assistant investigating a CICS problem may need to examine selected operational information. That doesn’t mean it should be permitted to change production resource definitions.
In each case, the distinction is between the information required to perform an investigation and the authority required to change the environment.
These capabilities should be separated wherever practical. The application should expose narrowly defined functions rather than unnecessarily broad administrative interfaces. Parameters should be validated. Sensitive operations should require independent authorisation. And the effective permissions should be restricted to what the application genuinely needs.
This is consistent with the recommendations in the OWASP guidance on Excessive Agency. The principle itself should be familiar to every mainframe security professional. Least privilege applies to AI-connected applications just as it applies to any other application.
What Happens When Something Goes Wrong?
There is another aspect that organisations should consider: Auditing.
Suppose an AI application invokes a tool that performs an unexpected operation against a protected resource. Traditional security records may help determine which identity was involved and what security-relevant activity occurred.
On z/OS, SMF can provide valuable information for security monitoring and investigation, including RACF-generated records where the relevant events are configured or otherwise eligible to be recorded. However, not every successful operation necessarily generates a security audit record. RACF auditing depends on the type of event, resource protection, audit settings and other applicable conditions.
There are also situations involving privileged or trusted processing that require particular attention when assessing audit coverage.
More importantly, even where a security event is recorded, that record may not explain why an AI agent decided to initiate the operation. For that, additional information is required from the AI application:
- Which request initiated the activity?
- Which information did the agent process?
- Which tool was selected?
- What parameters were supplied?
- Which security identity was used?
- What was the outcome?
- And was the operation influenced by untrusted information?
Ideally, the organisation should be able to correlate the application’s activity with the relevant middleware, API, subsystem and z/OS security records. This requires deliberate design. It is not something that can be assumed simply because SMF is enabled.
We Shouldn’t Forget the Traditional Security Principles
There is a tendency to treat AI security as something entirely new. And some of the risks are new. Prompt injection introduces a different way of influencing application behaviour. AI agents can also select and combine operations in ways that traditional applications may not have been designed to support. But many of the underlying security principles are not new.
We have been applying them to mainframe environments for decades:
- Validate untrusted input.
- Protect sensitive resources.
- Use least privilege.
- Separate responsibilities.
- Control delegated authority.
- Maintain appropriate audit records.
- And never assume that an application should be allowed to perform every operation available to its service identity.
The difference is that AI introduces another layer between the user’s original request and the operation ultimately performed. That layer needs to be considered in the security architecture.
The Real Security Challenge
I believe AI has enormous potential to improve mainframe operations, problem determination and the accessibility of technical knowledge. But as organisations begin connecting AI applications to operational tools, we need to pay particular attention to the authority available through those integrations.
The important question isn’t simply whether an AI agent can access a protected resource. It is whether the application has been designed to prevent the agent from requesting inappropriate operations in the first place.
RACF, ACF2 and Top Secret will continue to play an essential role in protecting mainframe resources. But they cannot independently determine whether an AI-generated request originated from a legitimate user instruction, an incorrect model interpretation or a malicious prompt embedded in external information. That responsibility must be addressed elsewhere in the application architecture. And perhaps that is the most important lesson.
An AI agent doesn’t need to bypass mainframe security to create a security problem. Sometimes, all it needs is access to a tool that has been given more authority than it should have.
Be the first to comment