Every Agent Followed the Rules: Identity and Authorization in Agentic Maximo

Category: AI in Maximo | Maximo Insider | September 25, 2026

There is a sentence in IBM's own published security guidance from September 2026 that ought to be printed on the wall of every Maximo program office considering agentic AI. It reads, in essence: every AI agent followed the rules, and the data still leaked. The point of that framing is not that agents misbehaved. It is that the rules themselves were scoped to a world where a human sits at the other end of every request, and agents broke that assumption without violating anything.

Within one week of that guidance, the Maximo ecosystem produced two developments that make the question urgent rather than theoretical. On September 22, 2026, Saudi Business Machines demonstrated Maxera on the IBM Maximo and watsonx stack at SFMA EXPO 2026 in Riyadh, describing a conversational multi-language interface for controlling enterprise operations and autonomous inspection extending safety into physical environments. The same week, practitioner writing on the IBM Bob and Maximo MCP server connection laid out the target architecture in plain terms: a user request goes into an AI assistant, which calls the Maximo MCP server, which invokes an authorized Maximo tool, which validates and returns a result or performs a controlled update.

Both of those are legitimate, well-intentioned designs. Neither of them, as publicly described, answers the question that will determine whether they survive a security review: whose identity is on the call when the agent touches Maximo, and which of Maximo's existing authorization mechanisms actually constrain it.

This article works through that question concretely. It covers what is now publicly on the record, why agentic access breaks the assumptions that Maximo's security model was built on, how IBM's own guidance maps onto Maximo's specific constructs, what a defensible authorization design looks like, and what the cost and operational implications are for programs that intend to put agents in front of real production data.

What Is Actually on the Record Now

Start with the concrete evidence, because the abstraction is where this discussion usually goes wrong.

The SBM demonstration at SFMA EXPO 2026 described two distinct AI surfaces on top of Maximo. The first is conversational multi-language control of enterprise operations, which is the natural-language-over-Maximo pattern: a user asks a question or issues an instruction in ordinary language, and an agent translates that into queries and actions against the asset management system. The second is autonomous inspection extending safety into physical environments, which is a different thing entirely: a robotic or sensor-driven agent performing inspection work in the field, presumably feeding findings back into the same platform.

The event context matters less than the fact that this was presented as a live partner capability for a national facilities market that the Saudi Minister of Municipalities and Housing described as worth more than fifty billion dollars. This is not a research prototype. It is a marketed solution for a market with serious operational consequences.

The second development is the technical architecture. Practitioner writing published September 15, 2026 described the IBM Bob to Maximo MCP server connection with unusual clarity. MCP, the Model Context Protocol, is an open standard that lets AI assistants connect to external tools and data sources. IBM Bob supports MCP servers. Maximo Application Suite 9.2 provides a Maximo MCP server that exposes authorized Maximo capabilities to AI agents. The described flow is direct: user request in Bob, then Maximo MCP server, then authorized Maximo tool, then validation, then a result or a controlled update, with a review-and-confirm gate before changes are committed. There is also a public MCP endpoint for DXL coding work that can be connected to an assistant with a single command, which demonstrates how low the barrier to connection has become.

The word that deserves attention in that architecture description is the one used twice: authorized. The design is only as strong as the definition of that term, and the definition is exactly what nobody has published.

Why Agentic Access Breaks Maximo's Security Assumptions

Maximo's security model is genuinely mature. It has security groups, application-level authorization, object-level authority including read, insert, delete, and save permissions per object, site and organization scoping, data restrictions through conditional expressions, and a signature security option that gates access to functionality rather than data. Over two decades this model has been tuned to answer a specific question: can this named human, in this role, do this thing to this record.

Agentic AI changes three of the assumptions underneath that question.

The first is the assumption that a human is the initiator. When a user asks an assistant a question and the assistant fulfills it, the effective initiator is ambiguous. Most implementations resolve this by running the agent under a service account with broad permissions, because scoping a service account to every possible user's entitlements is difficult and the agent needs to be able to answer whatever it is asked. The result is a well-known pattern: the human's own Maximo permissions are irrelevant, because the agent is not acting as the human. It is acting as itself, with the union of everything it was granted. A user who cannot see the maintenance cost object in the Maximo interface can often see it through the assistant, because the assistant's account can.

This is the "every agent followed the rules" failure in its Maximo form. The agent did exactly what it was authorized to do. The authorization was simply attached to the wrong principal.

The second broken assumption is that actions are discrete and attributable. A human clicking through Maximo generates a record with a user identifier, a timestamp, and usually an application context. An agent processing a conversational request may decompose it into a sequence of tool calls, some of them read-only lookups, some of them retrieving context from a retrieval layer, and some of them writing. If the audit trail shows a service account performing twenty operations in four seconds, the trail technically exists but it cannot answer the question an auditor will ask: who wanted this done and why. Attribution has to be carried deliberately, and it is not carried by default.

The third broken assumption is that the retrieval layer is inside the security boundary. This is the subtlest of the three and the one that most often escapes review. When an agent answers a question about asset history, it may do so by querying a vector store that was populated from Maximo records at some point in the past. That store may contain data from multiple sites, multiple organizations, records the current user should not see, and classification markings that the retrieval step ignores. Row-level security in Maximo does nothing for a vector store. The data left the boundary when it was indexed, and it carries no access metadata unless someone explicitly put it there.

Applying IBM's Own Guidance to Maximo Constructs

IBM's September 2026 guidance on agent security is unusually prescriptive, and it is worth mapping each recommendation to the Maximo features that can implement it, because the mapping is not obvious and it is where implementation effort actually goes.

The first recommendation is to treat AI identity as critical infrastructure and propagate identity end-to-end, using OAuth 2.0 token exchange or an on-behalf-of flow so that each tool call carries the calling user's identity all the way to the data layer. In Maximo terms, this means the MCP server cannot authenticate once and then operate under its own authority for the duration of a session. It means the token presented at the Maximo layer must resolve to the actual requesting user, so that Maximo's existing security groups and object authority apply unchanged. This is the single most important design decision in the whole architecture, because it makes every downstream authorization mechanism work without modification.

The second recommendation is to enforce authorization at a policy decision point outside the model, rather than relying on the model to police itself. Maximo already has such a point: the application server enforces object authority and conditional expressions regardless of what the client claims. The design implication is that the agent must be a client of Maximo's authorization, never a substitute for it. Any architecture where the agent decides what the user may see, and then requests it under its own broad authority, has moved the policy decision point into a component that can be prompted.

The third recommendation is to issue agents and service accounts short-lived, narrowly scoped credentials, and to inventory them as non-human identities with named owners and expiry dates. In a Maximo estate this is a direct extension of existing work: most organizations already maintain a set of integration user accounts, and those accounts are frequently over-privileged, undocumented, and permanent. Adding an agent identity to that population without an owner and an expiry makes an existing problem worse. The mitigation is procedural, and it is cheap: every agent identity gets a human owner, a defined scope, a rotation interval, and a decommission date.

The fourth recommendation is to authenticate every MCP server, plugin, and vector store with workload identity rather than shared secrets. Maximo estates have a long history of integration credentials stored in properties files. Workload identity is a genuine upgrade, and it matters more for agents because an agent that can call an external tool can be induced to call it with the wrong context if the tool does not authenticate the caller.

The fifth recommendation is to put a gateway in front of tool calls to log, rate-limit, and validate parameters. This addresses a risk that is specific to conversational interfaces: a user can ask for something enormous. A natural-language request for all work orders at a site is trivially easy to issue and potentially expensive to fulfill, both in system load and in consumption cost.

The remaining recommendations, scanning tool descriptions and retrieved content for injection, restricting egress so an agent cannot exfiltrate to arbitrary endpoints, maintaining a signed inventory of which agents may call which tools, and storing classification metadata on every vector store chunk filtered at query time, are all directly implementable and all currently unimplemented in most Maximo agent designs, because the public discussion has focused on capability rather than control.

The Consumption Model Nobody Budgeted For

There is a second, quieter problem with agentic Maximo that has nothing to do with security and everything to do with cost accounting, and it deserves attention because it constrains the same architecture.

Maximo Application Suite licensing includes a consumption-based component. Agentic loops consume resources in a way that ordinary user interaction does not. A single conversational request may generate multiple tool calls, each of which is a real query or transaction against the platform. A user who would once have run one report may now, through an assistant, trigger the equivalent of a dozen queries exploring the question. Multiply that by a user population and the consumption profile changes shape entirely.

The practical implication is that a gateway which rate-limits and validates parameters is not only a security control. It is a cost control. It is the place where you decide that a conversational request is allowed to fan out into a bounded number of operations, and where you can observe which users and which agent workflows are consuming disproportionately. Programs that deploy agentic access without that observability layer tend to discover the problem in the invoice rather than in the design review.

There is also a correctness angle. Agentic workflows that write to Maximo need a validation gate, and the publicly described architecture does include one: a review-and-confirm step before a controlled update is committed. That gate is where a human confirms the intent of the change. It is worth being explicit that this gate is a usability and safety control, not a security control. It does not constrain what the agent is permitted to do. It only constrains whether the last step completes. An agent with excessive authority and a confirmation gate still has excessive authority.

Practical Implications

If you are evaluating agentic access to Maximo, whether through an IBM-provided MCP server, a partner solution, or an internal build, the following sequence is the one that survives audit.

Start with identity, before capability. Decide explicitly whether the agent acts as the requesting user through a token exchange or on-behalf-of flow, or whether it acts as a service account. If it acts as a service account, document the scope, accept that the user's own Maximo entitlements are bypassed, and compensate with a narrower tool allowlist. If it acts as the user, verify that the token actually reaches the data layer and that Maximo's object authority and conditional expressions are still the deciding factor. Do not accept an assertion that identity is propagated. Test it by having a restricted user ask the assistant a question whose answer their Maximo group cannot see, and confirm they get nothing.

Second, inventory the non-human identities in your estate before adding more. The agent identity should have a named owner, a defined scope, a rotation schedule, and an expiry. If you cannot say who owns your existing integration accounts, fixing that is a prerequisite, not a parallel workstream.

Third, put a gateway between the agent and Maximo. Log the tool calls, validate the parameters, rate-limit the fan-out, and record which user originated each call. This is the component that makes both the security review and the consumption analysis tractable, and it is far cheaper to build than to retrofit.

Fourth, treat the retrieval layer as a separate security boundary. If your agent answers questions from an index rather than live queries, that index has its own access model, and row-level security in Maximo does not apply to it. Store classification and access-control metadata on every chunk and filter at query time, or accept that the index is a copy of your data with weaker controls than the original.

Fifth, scope the tool surface deliberately. The MCP server exposes authorized Maximo capabilities, and the word authorized is doing a great deal of work in that sentence. Enumerate exactly which capabilities are exposed and why, and start with read-only tools. The demonstration value of conversational querying is high and the risk is low. The write path is where the review burden sits.

Finally, be candid about what the confirmation gate does and does not do. It is a good control. It is not an authorization mechanism, and it should not be counted as one in a security design document.

The Bottom Line

Agentic AI is arriving in Maximo through real, marketed, dated partner solutions and through a publicly documented MCP architecture, and the capabilities being demonstrated are genuine. Conversational multi-language control of enterprise operations and autonomous field inspection are exactly the kinds of capability that asset-intensive organizations should be evaluating.

The gap is not capability. It is that the authorization model for agent access to Maximo has not been published, tested, or standardised, and IBM's own security research from September 2026 explains why that gap is dangerous in a way that is specific rather than theoretical. The failure mode is not an agent acting maliciously. It is an agent acting exactly as authorized, under an identity that was never scoped to the person making the request, against data that left the security boundary when it was indexed. Every rule was followed. The data still leaked.

The remedy is available and it is not exotic. Propagate user identity to the data layer so that Maximo's existing security model remains the policy decision point. Inventory and expire non-human identities. Put a gateway in front of tool calls to log, limit, and validate. Treat retrieval stores as their own boundary. Scope the exposed tool surface and start read-only. Do those five things and agentic Maximo becomes a controlled capability with an audit trail. Skip them and you have a conversational interface with the union of every permission you ever granted an integration account.